RFC Errata
Found 6 records.
Status: Verified (6)
RFC 9568, "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", April 2024
Source of RFC: rtgwg (rtg)
Errata ID: 7947
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2024-05-21
Verifier Name: James Guichard
Date Verified: 2024-06-27
Section 6.4.1 says:
o For each IPv4 address associated with the Virtual Router,
broadcast a gratuitous ARP message containing the Virtual
Router MAC address and with the target link-layer address
set to the Virtual Router MAC address.
It should say:
o For each IPv4 address associated with the Virtual Router,
broadcast a gratuitous ARP message containing the Virtual
Router IPv4 address and with the target link-layer address
set to the Virtual Router MAC address.
Notes:
The MAC address is specified instead of the IPv4 address.
Errata ID: 7949
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2024-05-21
Verifier Name: James Guichard
Date Verified: 2024-06-27
Section 6.4.2 says:
o For each IPv4 address associated with the Virtual Router,
broadcast a gratuitous ARP message containing the Virtual
Router MAC address and with the target link-layer address
set to the Virtual Router MAC address.
It should say:
o For each IPv4 address associated with the Virtual Router,
broadcast a gratuitous ARP message containing the Virtual
Router IPv4 address and with the target link-layer address
set to the Virtual Router MAC address.
Notes:
The MAC address is specified instead of the IPv4 address.
Errata ID: 8298
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Quentin Armitage
Date Reported: 2025-02-17
Verifier Name: Jim Guichard
Date Verified: 2025-03-06
Section 7.1 says:
It MUST verify that the VRID is configured on the receiving
interface and the local router is not the IPvX address owner
(Priority = 255 (decimal)).
If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.
It should say:
It MUST verify that the VRID is configured on the receiving
interface.
If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.
It SHOULD verify that the local router is not the IPvX address owner
(Priority = 255 (decimal)) and log the event (subject to
rate-limiting) and MAY indicate via network management that a
misconfiguration was detected.
Notes:
Although it is clearly a configuration error, if two (or more) VRRP routers are configured as the address owner for the same VRID, if received VRRP packets are just dropped (as specified in section 7.1), all such routers will remain in Active state, will continue sending VRRP adverts, and will respond to ARP/ND requests. This will make communication with any VIP unachievable, or at best unreliable.
If the VRRP packets are not dropped, but processed in the normal way, in section 6.4.3 - "Active", following "If an ADVERTISEMENT is received", then:
. If the Priority in the ADVERTISEMENT is greater than the
local Priority or the Priority in the ADVERTISEMENT is equal
to the local Priority and the primary IPvX address of the
sender is greater than the local primary IPvX address (based
on an unsigned integer comparison of the IPvX addresses in
network byte order), then:
...
Transition to the {Backup} state
will cause all except one of the VRRP routers to revert to Backup state, and the VRRP instance will be stable.
Errata ID: 8299
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Quentin Armitage
Date Reported: 2025-02-17
Verifier Name: Jim Guichard
Date Verified: 2025-03-06
Section 7.1 says:
* It MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)). If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event (subject to rate-limiting), and MAY indicate via network management that an error occurred.
It should say:
* It MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)). * It MUST verify that IPvX Addr Count is non zero. If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event (subject to rate-limiting), and MAY indicate via network management that an error occurred.
Notes:
The only change above is adding:
* It MUST verify that IPvX Addr Count is non zero.
This is due to section 5.2.5 requiring it:
5.2.5. IPvX Addr Count
The IPvX Addr Count field is the number of either IPv4 addresses or IPv6 addresses contained in this VRRP advertisement. The minimum value is 1. If the received count is 0, the VRRP advertisement MUST be ignored.
Errata ID: 8300
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Quentin Armitage
Date Reported: 2025-02-17
Verifier Name: Jim Guichard
Date Verified: 2025-03-06
Section 7.1 says:
* It MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)). If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event (subject to rate-limiting), and MAY indicate via network management that an error occurred.
It should say:
* It MUST verify that the VRID is configured on the receiving
interface and the local router is not the IPvX address owner
(Priority = 255 (decimal)).
* If the received packet is an IPv6 packet, then:
- It MUST verify that the first address in the IPvX Address(es)
field is an IPv6 link-local address.
If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.
Notes:
The change only adds checking that the first IPv6 address is link-local.
Section 5.2.9 states:
For IPv6, the first address MUST be the IPv6 link-local address associated with the Virtual Router.
Section 6.1 also states (although this may relate to the configuration rather than the VRRP packet contents):
IPv6_Addresses One or more IPv6 addresses associated with this Virtual Router. Configured list of addresses with no default. The first address MUST be the Link-Local address associated with the Virtual Router.
Errata ID: 8301
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Quentin Armitage
Date Reported: 2025-02-17
Verifier Name: Jim Guichard
Date Verified: 2025-03-06
Section 6.1 says:
Advertisement_Interval Time interval between VRRP Advertisements (centiseconds) sent by this Virtual Router. Default is 100 centiseconds (1 second). and section 7.1 says: * It MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)). If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event (subject to rate-limiting), and MAY indicate via network management that an error occurred.
It should say:
Advertisement_Interval Time interval between VRRP Advertisements (centiseconds) sent by this Virtual Router. Configurable value in the range 1-4095 (centiseconds). Default is 100 centiseconds (1 second). and section 7.1 should say: * It MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)). * It MUST verify that the Max Advertise Interval is non zero. If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event (subject to rate-limiting), and MAY indicate via network management that an error occurred.
Notes:
The Skew_Time and Active_Down_Time are calculated by multiplying by Active_Adver_Interval which is the Advertisement_Interval of the current active virtual router. A value of 0 for the Active_Adver_Interval will result in Skew_Time and Active_Down_Interval being 0 (centiseconds). The consequence of this is that all backup routers will immediately time out the Active_Down_Interval and transition to Active state. All but the lowest priority virtual router will send an advert, all virtual routes will keep timing out and sending VRRP adverts and the LAN will be flooded with VRRP packets.
It causes mayhem (I have tried it)!