Experimental

RFC 3768 - Virtual Router Redundancy Protocol (VRRP)

Every requirement this repository extracted from RFC 3768, 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 ways80.5%33 of 41 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 reason12.2%5 of 41 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 41 gated MUSTs

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

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

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

No test at all0.0%0 of 41 gated MUSTs

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

Proven by a recorded break57.7%82 of 142 tagged units

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

Neutral

measures that are neither good news nor bad

Gated MUSTs41of 52 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 scope3of 41 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 applicable7.3%3 of 41 gated MUSTs

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

Met below Ze0.0%0 of 41 gated MUSTs

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

Optional feature declined0.0%0 of 41 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

The 8 shares marked as a part above are the whole of the 41 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	ok	green at zero, RED above it: a binding obligation nothing exercises is a claim with nothing behind it, whether or not a reason is stated
Not applicable	neutral	no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim
Met below Ze	neutral	no color: an obligation met below Ze is neither a test Ze wrote nor work Ze owes, and the two green shares above are what says how much Ze proves itself
Optional feature declined	neutral	no color: an obligation whose condition Ze never meets is neither an achievement nor a failure. The absent FEATURE is disclosed on the RFC's own status row, as an implementation gap a later scope decision can revisit
Proven by a recorded break	ok	green at every value: an observed break is the outcome the discrimination gate exists to produce. The denominator is TAGGED UNITS, not obligations, so this share is not one of the parts above
Audit verdicts	warn	RED on the first weak, wrong or unimplemented verdict, amber while a verdict is no longer current or a gated MUST is unjudged, green when every one is judged sound and current

At a glance

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

Enrolment

Enrolled: VRRPv2 advertisement format, election and timers, virtual-MAC ownership, and the IPv4 Master dataplane, including redirect source selection for non-owner virtual routers.

What the public ledger says

Status: Experimental

What the ledger says is covered

Opt-in via version 2. Whole-second Advertisement_Interval encoding, v2 advert format, the v2 receive-validation ladder (version, complete-packet, checksum, VRID, Auth Type 0, interval-mismatch discard, address-list discard), the Section 6.4 state machine (priority/master election, skew time, preemption, silent losing-advert discard), virtual-MAC ownership of the VIP via a per-group macvlan, and the v2 rejection rules (no accept-mode, no IPv6).

What the ledger says remains:

RFC 3768 authentication types are deliberately not implemented: RFC 9568 Section 9 removed them as providing no real security. Same VRRP experimental status.

Coverage

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

Positive and negative tests (33): RFC3768-5.2.3-2, RFC3768-5.3.2-1, RFC3768-5.3.4-1, RFC3768-5.3.4-2, RFC3768-5.3.6-1, RFC3768-6.4.2-1, RFC3768-6.4.2-2, RFC3768-6.4.2-3, RFC3768-6.4.2-4, RFC3768-6.4.2-5, RFC3768-6.4.2-6, RFC3768-6.4.2-7, RFC3768-6.4.2-8, RFC3768-6.4.3-1, RFC3768-6.4.3-2, RFC3768-6.4.3-3, RFC3768-6.4.3-4, RFC3768-6.4.3-5, RFC3768-6.4.3-6, RFC3768-6.4.3-7, RFC3768-6.4.3-8, RFC3768-6.4.3-9, RFC3768-7.1-1, RFC3768-7.1-2, RFC3768-7.1-3, RFC3768-7.1-4, RFC3768-7.1-5, RFC3768-7.1-6, RFC3768-7.1-7, RFC3768-7.1-8, RFC3768-8.1-1, RFC3768-8.2-1, RFC3768-8.2-4

Annotated (including scoped evidence) (8): RFC3768-5.2.2-1, RFC3768-5.2.3-1, RFC3768-7.2-1, RFC3768-7.2-2, RFC3768-7.2-3, RFC3768-7.2-4, RFC3768-8.3-1, RFC3768-9.2-1

Requirements

Requirement	Level	Section	Tests
`RFC3768-5.2.2-1`	Routers MUST NOT forward a datagram with this destination address regardless of its TTL. (§5.2.2)
	MUST NOT	5.2.2	positive`no test`no positive test negative`no test`no negative test {not-applicable}: the VRRP plugin performs no IP datagram forwarding -- instance.onPacket internal/plugins/vrrp/instance.go:453 consumes each received advert into the FSM and never re-emits it, and tx scopes adverts to link-local multicast with IP_MULTICAST_LOOP 0 at internal/plugins/vrrp/transport/backend_linux.go:143
`RFC3768-5.2.3-1`	The TTL MUST be set to 255. (§5.2.3)
	MUST	5.2.3	positive`unit/verifyTestSendAdvertIPv4HeaderTTLProtoDst` negative`no test`no negative test {single-polarity}: buildIPv4Header unconditionally sets TTL 255 at internal/plugins/vrrp/transport/transport.go:562, so no input yields a different TTL -- the rx TTL!=255 discard is the separate RFC3768-5.2.3-2
`RFC3768-5.2.3-2`	A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet. (§5.2.3, §7.1)
	MUST	5.2.3	positive`unit/verifyTestDecodeGoldenV2` positive`unit/verifyTestDecodeV2DiscardsTTLNot255` negative`unit/verifyTestDecodeV2DiscardsTTLNot255` negative`unit/verifyTestNegativeReferenceBugs`
`RFC3768-5.3.2-1`	A packet with unknown type MUST be discarded. (§5.3.2)
	MUST	5.3.2	positive`unit/verifyTestDecodeGoldenV2` positive`unit/verifyTestDecodeV2DiscardsUnknownType` negative`unit/verifyTestDecodeV2DiscardsUnknownType` negative`unit/verifyTestValidationOrder`
`RFC3768-5.3.4-1`	The priority value for the VRRP router that owns the IP address(es) associated with the virtual router MUST be 255 (decimal). (§5.3.4)
	MUST	5.3.4	positive`unit/verifyTestOwnerAutoDetection` positive`unit/verifyTestV2OwnerRunsAtPriority255` negative`unit/verifyTestOwnerAutoDetection` negative`unit/verifyTestV2OwnerRunsAtPriority255`
`RFC3768-5.3.4-2`	VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal). (§5.3.4)
	MUST	5.3.4	positive`unit/verifyTestBoundaryPriority` positive`unit/verifyTestV2BoundaryPriority` negative`unit/verifyTestBoundaryPriority` negative`unit/verifyTestV2BoundaryPriority`
`RFC3768-5.3.6-1`	A packet with unknown authentication type or that does not match the locally configured authentication method MUST be discarded. (§5.3.6, §7.1)
	MUST	5.3.6	positive`unit/verifyTestDecodeGoldenV2` positive`unit/verifyTestDecodeV2DiscardsUnknownOrUnconfiguredAuthType` negative`unit/verifyTestDecodeV2DiscardsUnknownOrUnconfiguredAuthType` negative`unit/verifyTestNegativeReferenceBugs`
`RFC3768-6.4.2-1`	- MUST NOT respond to ARP requests for the IP address(s) associated with the virtual router. (§6.4.2)
	MUST NOT	6.4.2	positive`unit/verifyTestInstanceStartupNonOwnerGoesBackup` positive`unit/verifyTestV2BackupHoldsNoVirtualAddress` negative`unit/verifyTestInstanceOwnerStartupGoesMaster` negative`unit/verifyTestV2BackupHoldsNoVirtualAddress`
`RFC3768-6.4.2-2`	- 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`
`RFC3768-6.4.2-3`	- MUST NOT accept packets addressed to the IP address(es) associated with the virtual router. (§6.4.2)
	MUST NOT	6.4.2	positive`unit/verifyTestInstanceStartupNonOwnerGoesBackup` positive`unit/verifyTestV2BackupHoldsNoVirtualAddress` negative`unit/verifyTestInstanceOwnerStartupGoesMaster` negative`unit/verifyTestV2BackupHoldsNoVirtualAddress`
`RFC3768-6.4.2-4`	If a Shutdown event is received, then: o Cancel the Master_Down_Timer o Transition to the {Initialize} state (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestV2BackupShutdown` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestV2BackupShutdown`
`RFC3768-6.4.2-5`	If the Master_Down_Timer fires, then: o Send an ADVERTISEMENT o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router o Set the Adver_Timer to Advertisement_Interval o Transition to the {Master} state (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestAnnounceMasterFramesPerAddress` positive`unit/verifyTestFSMMasterDownPromotion` positive`unit/verifyTestPromotionSetsAdverTimerToOwnInterval` negative`unit/verifyTestFSMStaleTimerGenerationIgnored` negative`unit/verifyTestPromotionSetsAdverTimerToOwnInterval`
`RFC3768-6.4.2-6`	If the Priority in the ADVERTISEMENT is Zero, then: o Set the Master_Down_Timer to Skew_Time (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestV2BackupPriorityZeroSetsSkewTime` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestV2BackupPriorityZeroSetsSkewTime`
`RFC3768-6.4.2-7`	If Preempt_Mode is False, or If the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: o Reset the Master_Down_Timer to Master_Down_Interval (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestV2BackupResetsOrDiscards` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestV2BackupResetsOrDiscards`
`RFC3768-6.4.2-8`	If Preempt_Mode is False, or If the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: o Reset the Master_Down_Timer to Master_Down_Interval else: o Discard the ADVERTISEMENT (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestV2BackupResetsOrDiscards` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestV2BackupResetsOrDiscards`
`RFC3768-6.4.3-1`	- MUST respond to ARP requests for the IP address(es) associated with the virtual router. (§6.4.3, §8.2)
	MUST	6.4.3	positive`unit/verifyTestDataplaneApplyIPv4SetsRecipe` positive`unit/verifyTestPromotionInstallsIPv4AddressOnVirtualMACDevice` positive`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly` negative`unit/verifyTestDataplaneRestoreOnLastGroup` negative`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`
`RFC3768-6.4.3-2`	- 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`
`RFC3768-6.4.3-3`	- MUST NOT accept packets addressed to the IP address(es) associated with the virtual router if it is not the IP address owner. (§6.4.3)
	MUST NOT	6.4.3	positive`unit/verifyTestActiveV2RouterAcceptsOnlyWhenItOwnsTheAddress` negative`unit/verifyTestActiveV2RouterAcceptsOnlyWhenItOwnsTheAddress`
`RFC3768-6.4.3-4`	- MUST accept packets addressed to the IP address(es) associated with the virtual router if it is the IP address owner. (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestActiveV2RouterAcceptsOnlyWhenItOwnsTheAddress` positive`unit/verifyTestInstanceOwnerStartupGoesMaster` negative`unit/verifyTestActiveV2RouterAcceptsOnlyWhenItOwnsTheAddress` negative`unit/verifyTestInstanceStartupNonOwnerGoesBackup`
`RFC3768-6.4.3-5`	If a Shutdown event is received, then: o Cancel the Adver_Timer o Send an ADVERTISEMENT with Priority = 0 o Transition to the {Initialize} state (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestInstanceShutdownAsMasterSendsPriorityZero` positive`unit/verifyTestV2MasterShutdown` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestV2MasterShutdown`
`RFC3768-6.4.3-6`	If the Adver_Timer fires, then: o Send an ADVERTISEMENT o Reset the Adver_Timer to Advertisement_Interval (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestV2MasterAdverTimerFires` negative`unit/verifyTestFSMStaleTimerGenerationIgnored` negative`unit/verifyTestV2MasterAdverTimerFires`
`RFC3768-6.4.3-7`	If the Priority in the ADVERTISEMENT is Zero, then: o Send an ADVERTISEMENT o Reset the Adver_Timer to Advertisement_Interval (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestV2MasterPriorityZero` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestV2MasterPriorityZero`
`RFC3768-6.4.3-8`	If the Priority in the ADVERTISEMENT is greater than the local Priority, or If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IP Address of the sender is greater than the local primary IP Address, then: o Cancel Adver_Timer o Set Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestInstanceTieBreakComparesTheAdvertisementSource` positive`unit/verifyTestInstanceV2TieBreakDemotionRestartsTheTimers` positive`unit/verifyTestV2MasterYieldsToAHigherPriority` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestInstanceTieBreakComparesTheAdvertisementSource` negative`unit/verifyTestV2MasterYieldsToAHigherPriority`
`RFC3768-6.4.3-9`	If the Priority in the ADVERTISEMENT is greater than the local Priority, or If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IP Address of the sender is greater than the local primary IP Address, then: o Cancel Adver_Timer o Set Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state else: o Discard ADVERTISEMENT (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestV2MasterDemotesOrDiscards` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestV2MasterDemotesOrDiscards`
`RFC3768-7.1-1`	MUST verify the VRRP version is 2. (§7.1)
	MUST	7.1	positive`unit/verifyTestDecodeGoldenV2` negative`unit/verifyTestNegativeReferenceBugs`
`RFC3768-7.1-2`	MUST verify that the received packet contains the complete VRRP packet (including fixed fields, IP Address(es), and Authentication Data). (§7.1)
	MUST	7.1	positive`unit/verifyTestDecodeGoldenV2` positive`unit/verifyTestDecodeV2DiscardsIncompletePacket` negative`unit/verifyTestDecodeV2DiscardsIncompletePacket` negative`unit/verifyTestValidationOrder`
`RFC3768-7.1-3`	MUST verify the VRRP checksum. (§7.1)
	MUST	7.1	positive`unit/verifyTestDecodeGoldenV2` negative`unit/verifyTestDecodeV2ChecksumCorrupt`
`RFC3768-7.1-4`	MUST verify that the VRID is configured on the receiving interface and the local router is not the IP Address owner (Priority equals 255 (decimal)). (§7.1)
	MUST	7.1	positive`unit/verifyTestDecodeGoldenV2` positive`unit/verifyTestInstanceV2OwnerDiscardsAdvert` positive`unit/verifyTestRxAdvertScopedToReceivingInterface` positive`unit/verifyTestRxVRIDCheckedOnTheReceivingInterface` negative`unit/verifyTestInstanceV2OwnerDiscardsAdvert` negative`unit/verifyTestRxAdvertScopedToReceivingInterface` negative`unit/verifyTestRxVRIDCheckedOnTheReceivingInterface` negative`unit/verifyTestValidationOrder`
`RFC3768-7.1-5`	MUST verify that the Auth Type matches the locally configured authentication method for the virtual router and perform that authentication method. (§7.1)
	MUST	7.1	positive`unit/verifyTestDecodeGoldenV2` negative`unit/verifyTestNegativeReferenceBugs`
`RFC3768-7.1-6`	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`
`RFC3768-7.1-7`	If the packet was not generated by the address owner (Priority does not equal 255 (decimal)), the receiver MUST drop the packet, otherwise continue processing. (§7.1)
	MUST	7.1	positive`unit/verifyTestInstanceV2AddressListMatchReachesFSM` positive`unit/verifyTestInstanceV2AddressListMismatchFromOwnerContinues` negative`unit/verifyTestInstanceV2AddressListMismatchDrops`
`RFC3768-7.1-8`	- MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router (§7.1)
	MUST	7.1	positive`unit/verifyTestDecodeGoldenV2` negative`unit/verifyTestDecodeV2IntervalMismatchDiscard` negative`unit/verifyTestValidationOrder`
`RFC3768-7.2-1`	Fill in the VRRP packet fields with the appropriate virtual router configuration state - Compute the VRRP checksum (§7.2)
	MUST	7.2	positive`unit/verifyTestEncodeGoldenV2` negative`no test`no negative test {single-polarity}: a golden encode pins every field and the checksum -- WriteTo internal/plugins/vrrp/packet/packet.go:251 plus FillChecksum internal/plugins/vrrp/packet/checksum.go:86 -- while a corrupted-encoding rejection is the separate receive requirement RFC3768-7.1-3
`RFC3768-7.2-2`	Set the source MAC address to Virtual Router MAC Address (§7.2)
	MUST	7.2	positive`unit/verifyTestConstants` positive`unit/verifyTestTxAdvertV4OnWire` negative`no test`no negative test {single-polarity}: the source MAC is the virtual-router MAC from packet.VirtualMAC internal/plugins/vrrp/packet/packet.go:97 egressed by binding the tx socket to the vMAC macvlan internal/plugins/vrrp/transport/backend_linux.go:133, a deterministic derivation with no input that yields a different MAC
`RFC3768-7.2-3`	Set the source IP address to interface primary IP address (§7.2)
	MUST	7.2	positive`unit/verifyTestSendAdvertUsesParentPrimaryV4Source` positive`unit/verifyTestTxAdvertV4OnWire` negative`no test`no negative test {single-polarity}: the source IP is the parent unit primary IPv4 from resolveParentPrimaryV4 internal/plugins/vrrp/transport/transport.go:573, a deterministic selection re-resolved on address change, with no input that yields a wrong-source advert
`RFC3768-7.2-4`	Set the IP protocol to VRRP - Send the VRRP packet to the VRRP IP multicast group (§7.2)
	MUST	7.2	positive`unit/verifyTestSendAdvertIPv4HeaderTTLProtoDst` positive`unit/verifyTestTxAdvertV4OnWire` negative`no test`no negative test {single-polarity}: buildIPv4Header sets IP protocol 112 at internal/plugins/vrrp/transport/transport.go:563 and SendAdvert targets 224.0.0.18 at internal/plugins/vrrp/transport/backend_linux.go:256, both constants with no input that changes them
`RFC3768-8.1-1`	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; lowercase "must" in the RFC)
	MUST	8.1	positive`unit/verifyTestVRRPRedirectSourceFollowsVirtualMAC` negative`unit/verifyTestVRRPRedirectSourceFollowsVirtualMAC`
`RFC3768-8.2-1`	The Master virtual router MUST NOT respond with its physical MAC address. (§8.2)
	MUST NOT	8.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`
`RFC3768-8.2-4`	When a host sends an ARP request for one of the virtual router IP addresses, the Master virtual router MUST respond to the ARP request with the virtual MAC address for the virtual router. (§8.2)
	MUST	8.2	positive`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly` positive`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly` negative`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly` negative`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly`
`RFC3768-8.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.3; lowercase "must" in the RFC)
	MUST	8.3	positive`no test`no positive test negative`no test`no negative test {not-applicable}: ze performs no proxy ARP for virtual addresses -- the per-group virtual-MAC macvlan answers ARP for the VIP directly (createMacvlan internal/plugins/vrrp/register.go:329 plus the sole-responder sysctl recipe internal/plugins/vrrp/dataplane_linux.go:64), and no proxy-ARP path exists
`RFC3768-9.2-1`	The functional address mode of operation MUST be implemented by routers supporting VRRP on token ring. (§9.2)
	MUST	9.2	positive`no test`no positive test negative`no test`no negative test {not-applicable}: ze supports only Ethernet-family parents (ethernet, veth, bridge, dummy -- internal/plugins/vrrp/groups.go:76) over AF_PACKET macvlan transport internal/plugins/vrrp/transport/backend_linux.go, with no token-ring transport, so the functional-address mode has no applicable code path
`RFC3768-5.3.10-1`	The authentication string is currently only used to maintain backwards compatibility with RFC 2338. It SHOULD be set to zero on transmission and ignored on reception. (§5.3.10)
	SHOULD	5.3.10	positive`no test`no positive test negative`no test`no negative test
`RFC3768-7.1-9`	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
`RFC3768-7.1-10`	MAY verify that "Count IP Addrs" and the list of IP Address matches the IP_Addresses 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
`RFC3768-7.1-11`	MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router If the above check 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
`RFC3768-8.2-2`	When a VRRP router restarts or boots, it SHOULD not send any ARP messages with its physical MAC address for the IP address it owns, it should only send ARP messages that include Virtual MAC addresses. (§8.2)
	SHOULD NOT	8.2	positive`no test`no positive test negative`no test`no negative test
`RFC3768-8.2-3`	When configuring an interface, VRRP routers should broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address on that interface. - At system boot, when initializing interfaces for VRRP operation; delay gratuitous ARP requests and ARP responses until both the IP address and the virtual router MAC address are configured. (§8.2)
	SHOULD	8.2	positive`no test`no positive test negative`no test`no negative test
`RFC3768-8.4-1`	A VRRP router SHOULD not forward packets addressed to the IP Address(es) it becomes Master for if it is not the owner. (§8.4)
	SHOULD NOT	8.4	positive`no test`no positive test negative`no test`no negative test
`RFC3768-9.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. (§9.1)
	SHOULD	9.1	positive`no test`no positive test negative`no test`no negative test
`RFC3768-7.1-12`	MAY indicate via network management that an error occurred. - MAY verify that "Count IP Addrs" and the list of IP Address matches the IP_Addresses 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
`RFC3768-7.1-13`	MAY verify that "Count IP Addrs" and the list of IP Address matches the IP_Addresses configured for the VRID (§7.1)
	MAY	7.1	positive`no test`no positive test negative`no test`no negative test
`RFC3768-9.2-2`	Additionally, routers MAY support 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. (§9.2)
	MAY	9.2	positive`no test`no positive test negative`no test`no negative test

Gaps and untested MUSTs

Requirement	State	Reason
`RFC3768-5.2.2-1` Routers MUST NOT forward a datagram with this destination address regardless of its TTL. (§5.2.2)	no test	no test carries this requirement id; annotated {not-applicable}: the VRRP plugin performs no IP datagram forwarding -- instance.onPacket internal/plugins/vrrp/instance.go:453 consumes each received advert into the FSM and never re-emits it, and tx scopes adverts to link-local multicast with IP_MULTICAST_LOOP 0 at internal/plugins/vrrp/transport/backend_linux.go:143
`RFC3768-8.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.3; lowercase "must" in the RFC)	no test	no test carries this requirement id; annotated {not-applicable}: ze performs no proxy ARP for virtual addresses -- the per-group virtual-MAC macvlan answers ARP for the VIP directly (createMacvlan internal/plugins/vrrp/register.go:329 plus the sole-responder sysctl recipe internal/plugins/vrrp/dataplane_linux.go:64), and no proxy-ARP path exists
`RFC3768-9.2-1` The functional address mode of operation MUST be implemented by routers supporting VRRP on token ring. (§9.2)	no test	no test carries this requirement id; annotated {not-applicable}: ze supports only Ethernet-family parents (ethernet, veth, bridge, dummy -- internal/plugins/vrrp/groups.go:76) over AF_PACKET macvlan transport internal/plugins/vrrp/transport/backend_linux.go, with no token-ring transport, so the functional-address mode has no applicable code path

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.

`RFC3768-5.2.2-1`

Routers MUST NOT forward a datagram with this destination address regardless of its TTL. (§5.2.2)

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

No test carries RFC3768-5.2.2-1, so no unit is bound to it.

`RFC3768-5.2.3-1`

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

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 5.2.3 says "The TTL MUST be set to 255." TestSendAdvertIPv4HeaderTTLProtoDst 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 compares the TTL octet of the built IPv4 header with the literal 255, single-polarity per the row annotation. Verdict unchanged.

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

`RFC3768-5.2.3-2`

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

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 5.2.3 says "A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet." TestDecodeGoldenV2 lost only the assertion on the removed MsgOnlyChecksum flag, which carried no RFC 3768 content, and TestNegativeReferenceBugs gained the FillChecksum mode argument and an rfc5798-compatible lookup in N1 alone; verifyReceived returns before any mode is read for version 2, so the VRRPv2 decode under judgement is unchanged. TestDecodeV2DiscardsTTLNot255 still accepts the VRRPv2 golden at TTL 255 and refuses TTL 0/1/64/254 with ErrTTL. Verdict unchanged.

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

`RFC3768-5.3.2-1`

A packet with unknown type MUST be discarded. (§5.3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 5.3.2 says "A packet with unknown type MUST be discarded." TestDecodeGoldenV2 lost only the assertion on the removed MsgOnlyChecksum flag, which carried no RFC 3768 content, and TestNegativeReferenceBugs gained the FillChecksum mode argument and an rfc5798-compatible lookup in N1 alone; verifyReceived returns before any mode is read for version 2, so the VRRPv2 decode under judgement is unchanged. TestDecodeV2DiscardsUnknownType still refuses Type 0, 2 and 15 with ErrType over a recomputed checksum. Verdict unchanged.

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

`RFC3768-5.3.4-1`

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

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestV2OwnerRunsAtPriority255 extracts a group with version 2 and fatals unless Version reached the spec as v2; the owner configured at 120 must have EffectivePriority 255 under decrements 0, 1, 119 and 4064 and must advertise Priority 255 on startup; a v2 non-owner keeps 120 (negative). Records: revert EffectivePriority, both polarities, observed red.

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

`RFC3768-5.3.4-2`

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

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestV2BoundaryPriority validates version-2 groups (version asserted at extraction): 1 and 254 accepted, 0 and 255 refused with the range-check text 'is out of range; configure 1..254' (so no other check can satisfy the case), and a v2 non-owner at 100 floors at 1 under decrements 99, 100, 4064. Records: revert validateGroup, both polarities.

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

`RFC3768-5.3.6-1`

A packet with unknown authentication type or that does not match the locally configured authentication method MUST be discarded. (§5.3.6, §7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 5.3.6 says "A packet with unknown authentication type or that does not match the locally configured authentication method MUST be discarded." TestDecodeGoldenV2 lost only the assertion on the removed MsgOnlyChecksum flag, which carried no RFC 3768 content, and TestNegativeReferenceBugs gained the FillChecksum mode argument and an rfc5798-compatible lookup in N1 alone; verifyReceived returns before any mode is read for version 2, so the VRRPv2 decode under judgement is unchanged. Auth Type 1, 2, 3, 128 and 255 are still each refused with ErrAuthType and Auth Type 0 accepted. Verdict unchanged.

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

`RFC3768-6.4.2-1`

- MUST NOT respond to ARP requests for the IP address(s) 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: vrrp judge 2026-09-29 (independent): Forbidden: a v2 Backup answering ARP for the virtual address. TestV2BackupHoldsNoVirtualAddress starts a Version 2 non-owner, requires Backup, zero address installs and no acceptance filter; the v2 owner contrast is Master with exactly one install on the virtual-MAC device. Asserted at Ze's boundary (the address Ze installs for the kernel ARP responder), the lower-layer form ai/rules/rfc-compliance.md asks for; no ARP is observed on the wire. Records: revert doInstallVIPs, both polarities. The Backup's virtual-MAC macvlan is up (D-8) but holds no address, so it has nothing to answer for.

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

`RFC3768-6.4.2-2`

- 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

`RFC3768-6.4.2-3`

- MUST NOT accept packets addressed to the IP 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: vrrp judge 2026-09-29 (independent): Forbidden: a v2 Backup accepting packets addressed to the virtual address. Same unit as 6.4.2-1: a Version 2 Backup installs no address (so the kernel has no local route for it) and hands no acceptance filter; the v2 Master contrast installs it. Records: revert doInstallVIPs, both polarities. Forwarding of virtual-MAC frames by a Backup is the separate RFC3768-6.4.2-2 defect (D-8), not this row.

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

`RFC3768-6.4.2-4`

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

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestV2BackupShutdown runs a VRRPv2 Backup: Shutdown yields exactly [StopTimers, Backup->Initialize] and state Initialize; the canceled timer's later expiry does nothing. The exact action list pins both the cancel and the transition.

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

`RFC3768-6.4.2-5`

If the Master_Down_Timer fires, then: o Send an ADVERTISEMENT o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router o Set the Adver_Timer to Advertisement_Interval o Transition to the {Master} state (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestPromotionSetsAdverTimerToOwnInterval: a VRRPv2 Backup's live expiry yields exactly SendAdvert{100,2000}, InstallVIPs, AnnounceFailover, StartAdvertTimer{2s}, Backup->Master; an unarmed generation promotes nothing. TestAnnounceMasterFramesPerAddress checks each announced frame against literals: broadcast ARP request per VIP, sender and target hardware address 00-00-5e-00-01-0a, target protocol address the VIP, exactly the VIP set.

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

`RFC3768-6.4.2-6`

If the Priority in the ADVERTISEMENT is Zero, then: o Set the Master_Down_Timer to Skew_Time (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestV2BackupPriorityZeroSetsSkewTime: Priority 0 arms the literal 0.609375 s ((256-100)/256, not the v3 1.21875 s); non-zero Priority 1 arms the literal 6.609375 s Master_Down_Interval. Expectations no longer come from skewTime.

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

`RFC3768-6.4.2-7`

If Preempt_Mode is False, or If the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: o 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): TestV2BackupResetsOrDiscards on VRRPv2: equal, greater and Preempt-off lower each arm the literal local 6.609375 s and stay Backup; Preempt-on lower produces nothing and the earlier timer still promotes. No interval adoption is asserted for v2 (the old wrong v3 row is no longer the evidence).

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

`RFC3768-6.4.2-8`

If Preempt_Mode is False, or If the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: o Reset the Master_Down_Timer to Master_Down_Interval else: o Discard the ADVERTISEMENT (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): Same unit as RFC3768-6.4.2-7: the greater-priority case is now fed, so an '==' comparison fails; the discard branch is proven by no action plus the old timer still promoting.

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

`RFC3768-6.4.3-1`

- MUST respond to ARP requests for the IP address(es) associated with the virtual router. (§6.4.3, §8.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 (v2 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	unproven
negative	`TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestDataplaneApplyIPv4SetsRecipe`	unit/verify	unproven
positive	`TestPromotionInstallsIPv4AddressOnVirtualMACDevice`	unit/verify	revert, verified
positive	`TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`	unit/verify	revert, verified

`RFC3768-6.4.3-2`

- 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

`RFC3768-6.4.3-3`

- MUST NOT accept packets addressed to the IP address(es) associated with the virtual router if it is not the IP address owner. (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 re-read after RFC3768-6.4.3-4 tags were added to TestActiveV2RouterAcceptsOnlyWhenItOwnsTheAddress (body unchanged): Forbidden: a v2 non-owner Master accepting packets addressed to the virtual address. The Version 2 test fatals unless exactly one accept-filter call is made and errors unless accept=false for the non-owner and accept=true for the owner.

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

`RFC3768-6.4.3-4`

- MUST accept packets addressed to the IP address(es) associated with the virtual router if it is the IP address owner. (§6.4.3)

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: vrrp judge 2026-09-29 (independent): TestActiveV2RouterAcceptsOnlyWhenItOwnsTheAddress promotes a Version 2 group to Master and requires exactly one acceptance-filter call with accept=true for the owner (positive) and accept=false for the non-owner (negative), so an owner suppression or an acceptance granted to every Master goes red. Records: revert EffectiveAcceptMode, both polarities. The older tags on TestInstanceOwnerStartupGoesMaster/NonOwnerGoesBackup remain and add nothing.

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

`RFC3768-6.4.3-5`

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

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestV2MasterShutdown: a Version 2 owner Master receives Shutdown; the last advert carries Priority 0, state is Initialize, in.advert is nil, and after 10 s of fake clock no timer event and no further advert appear (Cancel Adver_Timer, Send Priority 0, Transition to Initialize, each asserted). Contrast: a v2 Backup shutting down sends nothing. Records: revert cancelTimers, both polarities. The FSM matrix row master/shutdown still runs v3.

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

`RFC3768-6.4.3-6`

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

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestV2MasterAdverTimerFires on VRRPv2: the live expiry yields exactly SendAdvert{100,2000}, StartAdvertTimer{2s}; an unarmed generation yields nothing.

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

`RFC3768-6.4.3-7`

If the Priority in the ADVERTISEMENT is Zero, then: o Send an ADVERTISEMENT o Reset the Adver_Timer to Advertisement_Interval (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestV2MasterPriorityZero on VRRPv2: Priority 0 yields exactly SendAdvert{100,2000}, StartAdvertTimer{2s} and stays Master; a non-zero lower-priority advert yields nothing.

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

`RFC3768-6.4.3-8`

If the Priority in the ADVERTISEMENT is greater than the local Priority, or If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IP Address of the sender is greater than the local primary IP Address, then: o Cancel Adver_Timer o Set Master_Down_Timer to Master_Down_Interval o 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): the previously missing v2 'Priority greater' clause is now TestV2MasterYieldsToAHigherPriority: a Version 2 Master (source 192.0.2.2) gets Priority 250 from the LOWER sender 192.0.2.1, so only priority decides; it must be Backup, in.advert nil, silent for two intervals, Backup at MDI-1ms and Master at MDI+1ms with MDI = 3 s + 56/256 s (RFC 3768 6.1); a Priority 150 advert from the greater 192.0.2.8 holds Master with the timer armed (negative). Records: revert demoteToBackup, both polarities. The equal-priority tie-break clause stays proven by TestInstanceTieBreakComparesTheAdvertisementSource and TestInstanceV2TieBreakDemotionRestartsTheTimers (records syncSourceLocked, senderWinsTieBreak, demoteToBackup).

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

`RFC3768-6.4.3-9`

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestV2MasterDemotesOrDiscards on VRRPv2: higher priority and equal priority from 192.0.2.200 (greater than .10 only unsigned) each yield exactly StopTimers, RemoveVIPs, StartMasterDownTimer{6.609375s literal}, Master->Backup; equal from a smaller sender and lower priority yield nothing and stay Master.

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

`RFC3768-7.1-1`

MUST verify the VRRP version is 2. (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 7.1 says "MUST verify the VRRP version is 2." TestDecodeGoldenV2 lost only the assertion on the removed MsgOnlyChecksum flag, which carried no RFC 3768 content, and TestNegativeReferenceBugs gained the FillChecksum mode argument and an rfc5798-compatible lookup in N1 alone; verifyReceived returns before any mode is read for version 2, so the VRRPv2 decode under judgement is unchanged. N9 still requires ErrVersion for a v3 packet at a v2 group and the reverse; the v2 golden decodes. Verdict unchanged.

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

`RFC3768-7.1-2`

MUST verify that the received packet contains the complete VRRP packet (including fixed fields, IP Address(es), and Authentication Data). (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 7.1 says "MUST verify that the received packet contains the complete VRRP packet (including fixed fields, IP Address(es), and Authentication Data)." TestDecodeGoldenV2 lost only the assertion on the removed MsgOnlyChecksum flag, which carried no RFC 3768 content, and TestNegativeReferenceBugs gained the FillChecksum mode argument and an rfc5798-compatible lookup in N1 alone; verifyReceived returns before any mode is read for version 2, so the VRRPv2 decode under judgement is unchanged. Cuts inside the fixed fields still return ErrTruncated and short Authentication Data or address lists ErrLength; the complete golden is accepted. Verdict unchanged.

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

`RFC3768-7.1-3`

MUST verify the VRRP checksum. (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 7.1 says "MUST verify the VRRP checksum." TestDecodeGoldenV2 lost only the assertion on the removed MsgOnlyChecksum flag, which carried no RFC 3768 content, and TestNegativeReferenceBugs gained the FillChecksum mode argument and an rfc5798-compatible lookup in N1 alone; verifyReceived returns before any mode is read for version 2, so the VRRPv2 decode under judgement is unchanged. TestDecodeV2ChecksumCorrupt still requires ErrChecksum on a flipped v2 checksum, and the golden G1 still verifies as a message-only sum. Verdict unchanged.

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

`RFC3768-7.1-4`

MUST verify that the VRID is configured on the receiving interface and the local router is not the IP Address owner (Priority equals 255 (decimal)). (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 7.1 says "MUST verify that the VRID is configured on the receiving interface and the local router is not the IP Address owner (Priority equals 255 (decimal))." TestDecodeGoldenV2 lost only the assertion on the removed MsgOnlyChecksum flag, which carried no RFC 3768 content, and TestNegativeReferenceBugs gained the FillChecksum mode argument and an rfc5798-compatible lookup in N1 alone; verifyReceived returns before any mode is read for version 2, so the VRRPv2 decode under judgement is unchanged. TestRxAdvertScopedToReceivingInterface 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, so the VRID 10 advert sent on the VRID-20 interface is still refused with ErrUnknownVRID and arrives on its own interface. Verdict unchanged; its discrimination records read unit-changed and need re-recording in the guest.

Polarity	Test	Kind and tier	Proof state
negative	`TestInstanceV2OwnerDiscardsAdvert`	unit/verify	revert, verified
negative	`TestValidationOrder`	unit/verify	unproven
negative	`TestRxVRIDCheckedOnTheReceivingInterface`	unit/verify	revert, verified
negative	`TestRxAdvertScopedToReceivingInterface`	unit/verify	revert, verified
positive	`TestInstanceV2OwnerDiscardsAdvert`	unit/verify	revert, verified
positive	`TestDecodeGoldenV2`	unit/verify	unproven
positive	`TestRxVRIDCheckedOnTheReceivingInterface`	unit/verify	revert, verified
positive	`TestRxAdvertScopedToReceivingInterface`	unit/verify	revert, verified

`RFC3768-7.1-5`

MUST verify that the Auth Type matches the locally configured authentication method for the virtual router and perform that authentication method. (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 7.1 says "MUST verify that the Auth Type matches the locally configured authentication method for the virtual router and perform that authentication method." TestDecodeGoldenV2 lost only the assertion on the removed MsgOnlyChecksum flag, which carried no RFC 3768 content, and TestNegativeReferenceBugs gained the FillChecksum mode argument and an rfc5798-compatible lookup in N1 alone; verifyReceived returns before any mode is read for version 2, so the VRRPv2 decode under judgement is unchanged. N8 still requires ErrAuthType for Auth Type 1; the golden type 0 decodes. Verdict unchanged.

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

`RFC3768-7.1-6`

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 3768 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. The per-check discard proof in TestInstanceRxFailedCheckIsDiscarded is unchanged, and an overlay mutant making instance.lookup hand Decode the rfc5798-compatible mode reddened that test and TestInstanceRxValidAdvertReachesFSM, so the receive path still reaches the checks. 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	unproven
positive	`TestInstanceRxFailedCheckIsDiscarded`	unit/verify	revert, verified

`RFC3768-7.1-7`

If the packet was not generated by the address owner (Priority does not equal 255 (decimal)), the receiver MUST drop the packet, otherwise continue processing. (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 7.1 says "If the packet was not generated by the address owner (Priority does not equal 255 (decimal)), the receiver MUST drop the packet, otherwise continue processing." The cited producer onPacket changed only by deleting the MsgOnlyChecksum counter block that ran after a successful Decode; the version 2 address-list comparison, the drop for a sender Priority other than 255 and the continue for Priority 255 are untouched. The three address-list tests still pin drop, continue and match. Verdict unchanged.

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

`RFC3768-7.1-8`

- MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 7.1 says "MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router". TestDecodeGoldenV2 lost only the assertion on the removed MsgOnlyChecksum flag, which carried no RFC 3768 content, and TestNegativeReferenceBugs gained the FillChecksum mode argument and an rfc5798-compatible lookup in N1 alone; verifyReceived returns before any mode is read for version 2, so the VRRPv2 decode under judgement is unchanged. The interval-mismatch cases still require ErrV2IntervalMismatch; the golden with the equal interval decodes. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestDecodeV2IntervalMismatchDiscard`	unit/verify	unproven
negative	`TestValidationOrder`	unit/verify	unproven
positive	`TestDecodeGoldenV2`	unit/verify	unproven

`RFC3768-7.2-1`

Fill in the VRRP packet fields with the appropriate virtual router configuration state - Compute the VRRP checksum (§7.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 7.2 says "Fill in the VRRP packet fields with the appropriate virtual router configuration state - Compute the VRRP checksum". TestEncodeGoldenV2 gained only the FillChecksum mode argument, and FillChecksum seeds a pseudo-header only when the version nibble is 3, so the VRRPv2 encode still has to equal the golden G1 byte for byte, checksum 0x92ED included. Single-polarity positive. Verdict unchanged.

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

`RFC3768-7.2-2`

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 3768 Section 7.2 says "Set the source MAC address to Virtual Router MAC Address". 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 VRRPv2 source MAC is still compared with 00-00-5e-00-01-0a. Verdict unchanged; the guest-only discrimination record reads unit-changed and is owed a re-record under QEMU.

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

`RFC3768-7.2-3`

Set the source IP address to interface primary IP address (§7.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 7.2 says "Set the source IP address to interface primary IP address". 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 VRRPv2 source must still be the primary 192.0.2.251 over a lower secondary. Verdict unchanged; the guest-only discrimination record reads unit-changed and is owed a re-record under QEMU.

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

`RFC3768-7.2-4`

Set the IP protocol to VRRP - Send the VRRP packet to the VRRP IP 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 3768 Section 7.2 says "Set the IP protocol to VRRP - Send the VRRP packet to the VRRP IP multicast group". TestTxAdvertV4OnWire and TestSendAdvertIPv4HeaderTTLProtoDst 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 protocol 112 and destination 224.0.0.18 comparisons are unchanged. Single-polarity per the row annotation. Verdict unchanged.

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

`RFC3768-8.1-1`

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; 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 3768 Section 8.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 integration record is owed a guest re-record.

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

`RFC3768-8.2-1`

The Master virtual router MUST NOT respond with its physical MAC address. (§8.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 8.2 says "The Master virtual router MUST NOT respond with its physical MAC address." 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 owner-filter ARP capture and its physical-MAC control are unchanged. Verdict unchanged; the integration record is owed a guest re-record.

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

`RFC3768-8.2-4`

When a host sends an ARP request for one of the virtual router IP addresses, the Master virtual router MUST respond to the ARP request with the virtual MAC address for the virtual router. (§8.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 3768 Section 8.2 says "When a host sends an ARP request for one of the virtual router IP addresses, the Master virtual router MUST respond to the ARP request with 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 owner-filter ARP capture and its physical-MAC control are unchanged. Verdict unchanged; the integration record is owed a guest 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

`RFC3768-8.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.3; lowercase "must" in the RFC)

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

No test carries RFC3768-8.3-1, so no unit is bound to it.

`RFC3768-9.2-1`

The functional address mode of operation MUST be implemented by routers supporting VRRP on token ring. (§9.2)

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

No test carries RFC3768-9.2-1, so no unit is bound to it.

Extraction sign-off

Field	Value
Reviewer	claude
Signed off	2026-09-21
Register	prose
Source	rfc/full/rfc3768.txt
Source fingerprint	47afb9c05728468f
Record	rfc/extraction/rfc3768.json
Mapped sentences	26
Declined as scope	8
Relocated to a spec, which Ze OWES	0
Unclassified	0

Sections

Section	Name	Sites	Disposition	Reason
`front`	not stated	1	walked	not stated
`1`	not stated	0	walked	not stated
`1.1`	not stated	0	walked	not stated
`1.2`	not stated	0	walked	not stated
`1.3`	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
`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.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	2	walked	not stated
`5.2.4`	not stated	0	walked	not stated
`5.3`	not stated	0	walked	not stated
`5.3.1`	not stated	0	walked	not stated
`5.3.2`	not stated	1	walked	not stated
`5.3.3`	not stated	0	walked	not stated
`5.3.4`	not stated	2	walked	not stated
`5.3.5`	not stated	0	walked	not stated
`5.3.6`	not stated	1	walked	not stated
`5.3.6.1`	not stated	0	walked	not stated
`5.3.6.2`	not stated	0	walked	not stated
`5.3.6.3`	not stated	0	walked	not stated
`5.3.7`	not stated	0	walked	not stated
`5.3.8`	not stated	0	walked	not stated
`5.3.9`	not stated	0	walked	not stated
`5.3.10`	not stated	0	walked	not stated
`6`	not stated	0	walked	not stated
`6.1`	not stated	0	walked	not stated
`6.2`	not stated	0	walked	not stated
`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	4	walked	not stated
`6.4.3`	not stated	5	walked	not stated
`7`	not stated	0	walked	not stated
`7.1`	not stated	5	walked	not stated
`7.2`	not stated	1	walked	not stated
`7.3`	not stated	0	walked	not stated
`8`	not stated	0	walked	not stated
`8.1`	not stated	1	walked	not stated
`8.2`	not stated	2	walked	not stated
`8.3`	not stated	1	walked	not stated
`8.4`	not stated	0	walked	not stated
`9`	not stated	0	walked	not stated
`9.1`	not stated	0	walked	not stated
`9.2`	not stated	2	walked	not stated
`9.3`	not stated	0	walked	not stated
`10`	not stated	1	walked	not stated
`11`	not stated	0	walked	not stated
`12`	not stated	0	walked	not stated
`12.1`	not stated	0	walked	not stated
`12.2`	not stated	0	walked	not stated
`13`	not stated	0	walked	not stated
`14`	not stated	0	walked	not stated
`15`	not stated	1	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	Table of contents line; the word Required is the title of Section 2.1, not an obligation.	Required Features . . . . . . . . . . . . . . . . . . . . . . 5 2.1.
`2:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Section heading 'Required Features'; a heading states no obligation.	Required Features
`3:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Overview prose with a lowercase must describing operator configuration across a LAN, not an implementation obligation: the sentence sits between 'A VRRP router may associate a virtual router with its real addresses' and 'However, there is no restriction against reusing a VRID with a different address mapping on different LANs.'	The mapping between VRID and addresses 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 'Sample Configuration 1'; the lowercase must describes what the example deployment does, not what an implementation owes.	In order to backup IP B, a second virtual router must be configured.
`7.1:5`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	Restates the discard half of the Adver Interval check mapped at site 7.1:4, which RFC3768-7.1-8 already carries ('discard the packet on mismatch').	If the above check fails, the receiver MUST discard the packet, SHOULD log the event and MAY indicate via network management that a misconfiguration was detected.
`9.2:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Descriptive prose about source route bridges with a lowercase 'required'; it states that a mechanism is needed, names none, and the token ring obligation itself is site 9.2:2.	- 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.
`10:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Security Considerations prose stating the negative, that no information in VRRP messages must be kept secret; lowercase must inside a denial of a requirement.	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.
`15:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	IETF Intellectual Property Statement boilerplate.	The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard.

Superseded

RFC 3768 is obsoleted by RFC 9568.

Requirement	Disposition	Now stated at	Reason
`RFC3768-5.2.2-1` Routers MUST NOT forward a datagram with this destination address regardless of its TTL. (§5.2.2)	restated	RFC9568-5.1.1.2-1	RFC 9568 Section 5.1.1.2 keeps the rule for IPv4 and adds the IPv6 counterpart at RFC9568-5.1.2.2-1 for ff02::12
`RFC3768-5.2.3-1` The TTL MUST be set to 255. (§5.2.3)	restated	RFC9568-5.1.1.3-1	RFC 9568 Section 5.1.1.3 keeps the IPv4 TTL of 255 and adds the IPv6 Hop Limit counterpart at RFC9568-5.1.2.3-1
`RFC3768-5.2.3-2` A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet. (§5.2.3, §7.1)	restated	RFC9568-5.1.1.3-2	RFC 9568 Section 5.1.1.3 keeps the discard rule for IPv4 and adds the IPv6 Hop Limit counterpart at RFC9568-5.1.2.3-2
`RFC3768-5.3.2-1` A packet with unknown type MUST be discarded. (§5.3.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 for any other value
`RFC3768-5.3.4-1` The priority value for the VRRP router that owns the IP address(es) associated with the virtual router MUST be 255 (decimal). (§5.3.4)	restated	RFC9568-5.2.4-1	RFC 9568 Section 5.2.4 keeps Priority 255 for the router owning the Virtual Router addresses, over both address families
`RFC3768-5.3.4-2` VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal). (§5.3.4)	restated	RFC9568-5.2.4-2	RFC 9568 Section 5.2.4 keeps the 1 to 254 range for backup routers
`RFC3768-5.3.6-1` A packet with unknown authentication type or that does not match the locally configured authentication method MUST be discarded. (§5.3.6, §7.1)	dropped	not stated	VRRPv3 removes authentication. RFC 9568 Section 9 states that VRRP for IPvX does not currently include any type of authentication, and its packet format carries no Auth Type field, so no unknown-or-mismatched Auth Type can be received. The octet that held Auth Type in VRRPv2 is the Reserve field of RFC 9568 Section 5.2.6
`RFC3768-6.4.2-1` - MUST NOT respond to ARP requests for the IP address(s) associated with the virtual router. (§6.4.2)	restated	RFC9568-6.4.2-1	RFC 9568 Section 6.4.2 keeps the rule for IPv4 ARP and adds the IPv6 counterparts, RFC9568-6.4.2-2 for Neighbor Solicitations and RFC9568-6.4.2-3 for Router Advertisements
`RFC3768-6.4.2-2` - 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 rule that a Backup Router discards packets whose destination link-layer address is the Virtual Router MAC
`RFC3768-6.4.2-3` - MUST NOT accept packets addressed to the IP 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 and states it over both address families
`RFC3768-6.4.2-4` If a Shutdown event is received, then: o Cancel the Master_Down_Timer o 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 Master_Down_Timer to Active_Down_Timer
`RFC3768-6.4.2-5` If the Master_Down_Timer fires, then: o Send an ADVERTISEMENT o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router o Set the Adver_Timer to Advertisement_Interval o Transition to the {Master} state (§6.4.2)	restated	RFC9568-6.4.2-7	RFC 9568 Section 6.4.2 keeps the whole timer-expiry sequence, renames the timer to Active_Down_Timer and the state to Active, and adds the IPv6 unsolicited Neighbor Advertisement beside the gratuitous ARP
`RFC3768-6.4.2-6` If the Priority in the ADVERTISEMENT is Zero, then: o 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
`RFC3768-6.4.2-7` If Preempt_Mode is False, or If the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: o 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, that the Backup Router adopts the Max Advertise Interval from the advertisement as Active_Adver_Interval before recomputing the timers
`RFC3768-6.4.2-8` If Preempt_Mode is False, or If the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: o Reset the Master_Down_Timer to Master_Down_Interval else: o Discard the ADVERTISEMENT (§6.4.2)	restated	RFC9568-6.4.2-10	RFC 9568 Section 6.4.2 keeps the discard rule for a lower-priority advertisement under Preempt_Mode
`RFC3768-6.4.3-1` - MUST respond to ARP requests for the IP address(es) associated with the virtual router. (§6.4.3, §8.2)	restated	RFC9568-6.4.3-1	RFC 9568 Section 6.4.3 keeps the ARP obligation for IPv4 and adds the IPv6 Neighbor Discovery counterparts at RFC9568-6.4.3-2, RFC9568-6.4.3-3 and RFC9568-6.4.3-4
`RFC3768-6.4.3-2` - 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 rule that the Active Router forwards packets whose destination link-layer address is the Virtual Router MAC
`RFC3768-6.4.3-3` - MUST NOT accept packets addressed to the IP address(es) associated with the virtual router if it is not the IP address owner. (§6.4.3)	restated	RFC9568-6.4.3-7	RFC 9568 Section 6.4.3 keeps the prohibition and narrows it, because VRRPv3 adds Accept_Mode: the Active Router refuses such packets only when it is neither the address owner nor configured with Accept_Mode True
`RFC3768-6.4.3-4` - MUST accept packets addressed to the IP address(es) associated with the virtual router if it is the IP address owner. (§6.4.3)	restated	RFC9568-6.4.3-6	RFC 9568 Section 6.4.3 keeps the owner case and widens it to Accept_Mode True
`RFC3768-6.4.3-5` If a Shutdown event is received, then: o Cancel the Adver_Timer o Send an ADVERTISEMENT with Priority = 0 o 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
`RFC3768-6.4.3-6` If the Adver_Timer fires, then: o Send an ADVERTISEMENT o Reset the Adver_Timer to Advertisement_Interval (§6.4.3)	restated	RFC9568-6.4.3-9	RFC 9568 Section 6.4.3 keeps the Adver_Timer expiry behaviour unchanged
`RFC3768-6.4.3-7` If the Priority in the ADVERTISEMENT is Zero, then: o Send an ADVERTISEMENT o 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
`RFC3768-6.4.3-8` If the Priority in the ADVERTISEMENT is greater than the local Priority, or If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IP Address of the sender is greater than the local primary IP Address, then: o Cancel Adver_Timer o Set Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state (§6.4.3)	restated	RFC9568-6.4.3-11	RFC 9568 Section 6.4.3 keeps the rule and states that the sender address comparison is an unsigned integer comparison in network byte order
`RFC3768-6.4.3-9` If the Priority in the ADVERTISEMENT is greater than the local Priority, or If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IP Address of the sender is greater than the local primary IP Address, then: o Cancel Adver_Timer o Set Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state else: o Discard ADVERTISEMENT (§6.4.3)	restated	RFC9568-6.4.3-12	RFC 9568 Section 6.4.3 keeps the discard and adds one step, that the Active Router immediately sends an advertisement so learning bridges relearn the segment. RFC 9568 Section 1.2 lists that addition as change 5
`RFC3768-7.1-1` MUST verify the VRRP version is 2. (§7.1)	restated	RFC9568-7.1-1	RFC 9568 Section 7.1 keeps the version check and changes the value it verifies from 2 to 3
`RFC3768-7.1-2` MUST verify that the received packet contains the complete VRRP packet (including fixed fields, IP Address(es), and Authentication Data). (§7.1)	restated	RFC9568-7.1-3	RFC 9568 Section 7.1 keeps the completeness check over the fixed fields and the address list. The Authentication Data half of the RFC 3768 check is gone with the field
`RFC3768-7.1-3` MUST verify the VRRP checksum. (§7.1)	restated	RFC9568-5.2.8-1	RFC 9568 moves the checksum definition to Section 5.2.8 and extends it, because the IPv6 checksum covers a pseudo-header. RFC 9568 Section 1.2 lists that as change 4
`RFC3768-7.1-4` MUST verify that the VRID is configured on the receiving interface and the local router is not the IP Address owner (Priority equals 255 (decimal)). (§7.1)	restated	RFC9568-7.1-4	RFC 9568 Section 7.1 keeps both halves of the check, that the VRID is configured on the receiving interface and that the local router is not the address owner
`RFC3768-7.1-5` MUST verify that the Auth Type matches the locally configured authentication method for the virtual router and perform that authentication method. (§7.1)	dropped	not stated	VRRPv3 removes authentication. RFC 9568 Section 7.1 lists no Auth Type check, its packet format carries no Auth Type field, and its Section 9 states that VRRP for IPvX does not currently include any type of authentication
`RFC3768-7.1-6` 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, and keeps the SHOULD log and MAY network-management indication beside it
`RFC3768-7.1-7` If the packet was not generated by the address owner (Priority does not equal 255 (decimal)), the receiver MUST drop the packet, otherwise continue processing. (§7.1)	dropped	not stated	RFC 9568 Section 7.1 removes the drop. The address-list check is a MAY at RFC9568-7.1-11, and on failure the receiver only SHOULD log the event and MAY indicate a misconfiguration. No sender-priority condition and no packet drop remain
`RFC3768-7.1-8` - MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router (§7.1)	restated	RFC9568-7.1-8	RFC 9568 Section 7.1 lowers the check from MUST to SHOULD and removes the drop, stating that the mismatch will not result in the VRRP packet being dropped. RFC 9568 Section 1.2 lists that as change 8. The field is also renamed and rescaled, from Adver Int in seconds to Max Advertise Interval in centiseconds
`RFC3768-7.2-1` 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
`RFC3768-7.2-2` 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
`RFC3768-7.2-3` Set the source IP address to interface primary IP address (§7.2)	restated	RFC9568-7.2-3	RFC 9568 Section 7.2 keeps the interface primary IPv4 address and adds the IPv6 case, where the source is the interface link-local address
`RFC3768-7.2-4` Set the IP protocol to VRRP - Send the VRRP packet to the VRRP IP multicast group (§7.2)	restated	RFC9568-7.2-4	RFC 9568 Section 7.2 keeps IP protocol 112 and adds the IPv6 destination group ff02::12 beside 224.0.0.18
`RFC3768-8.1-1` 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; lowercase "must" in the RFC)	unextracted	§8.1.1	RFC 9568 §8.1.1 restates it in the same words, and rfc/short/rfc9568.md declares no row for it
`RFC3768-8.2-1` The Master virtual router MUST NOT respond with its physical MAC address. (§8.2)	restated	RFC9568-8.1.2-1	RFC 9568 Section 8.1.2 keeps the prohibition for IPv4 ARP and adds the IPv6 Neighbor Discovery counterpart at RFC9568-8.2.2-1
`RFC3768-8.2-4` When a host sends an ARP request for one of the virtual router IP addresses, the Master virtual router MUST respond to the ARP request with the virtual MAC address for the virtual router. (§8.2)	restated	RFC9568-8.1.2-6	RFC 9568 Section 8.1.2 keeps the obligation, names the Master the Active Router, and states that the ARP response indicates the Virtual Router MAC address
`RFC3768-8.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.3; lowercase "must" in the RFC)	restated	RFC9568-8.1.3-1	RFC 9568 Section 8.1.3 keeps the Proxy ARP obligation and states it with an uppercase MUST
`RFC3768-9.2-1` The functional address mode of operation MUST be implemented by routers supporting VRRP on token ring. (§9.2)	dropped	not stated	RFC 9568 removes token ring. Its Section 1.2 lists as change 6 that the appendices describing operation over legacy technologies, FDDI, Token Ring and ATM LAN Emulation, were removed, so RFC 9568 states no functional-address obligation
`RFC3768-5.3.10-1` The authentication string is currently only used to maintain backwards compatibility with RFC 2338. It SHOULD be set to zero on transmission and ignored on reception. (§5.3.10)	dropped	not stated	VRRPv3 removes the Authentication Data field, so no obligation about its value remains. RFC 9568 Section 5.2.6 states the same zero-on-transmission and ignore-on-reception rule for its Reserve field at RFC9568-5.2.6-1, which is a different field: it occupies the octet VRRPv2 used for Auth Type
`RFC3768-7.1-9` 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 on a failed mandatory check and adds rate-limiting to it
`RFC3768-7.1-10` MAY verify that "Count IP Addrs" and the list of IP Address matches the IP_Addresses 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 on an address-list mismatch, adds rate-limiting, and states it in one sentence covering the Max Advertise Interval mismatch as well
`RFC3768-7.1-11` MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router If the above check fails, the receiver MUST discard the packet, SHOULD log the event (§7.1)	restated	RFC9568-7.1-9	RFC 9568 Section 7.1 merges this log with the address-list one into a single rate-limited recommendation, and renames the field to Max Advertise Interval
`RFC3768-8.2-2` When a VRRP router restarts or boots, it SHOULD not send any ARP messages with its physical MAC address for the IP address it owns, it should only send ARP messages that include Virtual MAC addresses. (§8.2)	restated	RFC9568-8.1.2-3	RFC 9568 Section 8.1.2 keeps the rule for IPv4 ARP and adds the IPv6 Neighbor Discovery counterpart at RFC9568-8.2.2-5
`RFC3768-8.2-3` When configuring an interface, VRRP routers should broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address on that interface. - At system boot, when initializing interfaces for VRRP operation; delay gratuitous ARP requests and ARP responses until both the IP address and the virtual router MAC address are configured. (§8.2)	restated	RFC9568-8.1.2-4	RFC 9568 Section 8.1.2 splits the sentence in two and raises one half. The gratuitous ARP on interface configuration stays a SHOULD at RFC9568-8.1.2-4, and the boot delay until both the address and the Virtual Router MAC are configured becomes a MUST at RFC9568-8.1.2-2
`RFC3768-8.4-1` A VRRP router SHOULD not forward packets addressed to the IP Address(es) it becomes Master for if it is not the owner. (§8.4)	restated	RFC9568-8.3.1-1	RFC 9568 Section 8.3.1 keeps the rule and states it over both address families
`RFC3768-9.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. (§9.1)	dropped	not stated	RFC 9568 removes FDDI. Its Section 1.2 lists as change 6 that the appendices describing operation over legacy technologies, FDDI, Token Ring and ATM LAN Emulation, were removed, so RFC 9568 states no unicast-MAC-filter recommendation
`RFC3768-7.1-12` MAY indicate via network management that an error occurred. - MAY verify that "Count IP Addrs" and the list of IP Address matches the IP_Addresses 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
`RFC3768-7.1-13` MAY verify that "Count IP Addrs" and the list of IP Address matches the IP_Addresses 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
`RFC3768-9.2-2` Additionally, routers MAY support 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. (§9.2)	dropped	not stated	RFC 9568 removes token ring. Its Section 1.2 lists as change 6 that the appendices describing operation over legacy technologies, FDDI, Token Ring and ATM LAN Emulation, were removed, so RFC 9568 states no unicast-mode permission