Hi Quentin, I don't think the fact that this is a "SHOULD" and not a "MUST" mandates that it has to be handled gracefully by the protocol. There are plenty of situations where violation of "SHOULDs" result in degraded or incorrect protocol behavior.
Also, I think that attempt to handle this misconfiguration beyond logging the event as currently specified is RFC 9568 is something that should be proposed in a draft rather than an Errata. Anyway, I'll let the AD decide. Thanks, Acee > On Feb 20, 2025, at 3:57 AM, Quentin Armitage <quen...@armitage.org.uk> wrote: > > Acee at al, > > Many thanks for your response. I do feel though that I should add a bit more > of my reasoning > for why I submitted this erratum. > > RFC 5798 in section 8.3.2 (Recommendations Regarding Setting Priority Values) > states: > > A priority value of 255 designates a particular router as the "IPvX address > owner". Care > must be taken not to configure more than one router on the link in this way > for a single > VRID. > > Routers with priority 255 will, as soon as they start up, preempt all > lower-priority > routers. No more than one router on the link is to be configured with > priority 255, > especially if preemption is set. > > RFC 9568 changes this to state: > > A priority value of 255 designates a particular router as the "IPvX address > owner" for the > VRID. VRRP Routers with priority 255 will, as soon as they start up, preempt > all lower- > priority routers. For a VRID, only a single VRRP Router on the link SHOULD be > configured > with priority 255. If multiple VRRP Routers advertising priority 255 are > detected, the > condition SHOULD be logged (subject to rate-limiting). > > My interpretation of this change is that RFC 9568 now explicitly permits, > through the use of > SHOULD rather than MUST, there to be more than one router with priority 255, > and that it is > therefore no longer a misconfiguration for more than one router to be > configured with > priority 255. > > In note though that section 5.2.4 (Priority) states that the address owner > MUST use priority > 255 and that backup routers MUST use priorities 1-254 and section 6.1 states > that priority > 255 is reserved for the router that owns the IPvX address and that 1-254 is > available for > backup routers. The use of "the" rather than "a" for "the address owner" and > "the router > than owns" does seem to infer that there can be only one router with priority > 255. > > I had assumed that the change to section 8.3.2 was intentional, and > therefore, in order to > allow that to work, section 7.1 (which sets out the functions to be performed > when a VRRP > packet is received) which states "MUST verify ... the local router is not the > IPvX address > owner (Priority - 255)", and that if the check fails "the receiver MUST > discard the packet" > needs to be changed to allow a receiver with local priority 255 to receive > and process VRRP > packets. If on the other hand the requirement is that only one router has > priority 255 then > section 8.3.2 needs to be changed to revert to the previous position, or > perhaps be stonger, > and state that there MUST NOT be more than one router with priority 255. > > In any event, my understanding is that the requirement in section 7.1 to drop > any received > VRRP packet if the receiver has local priority 255 is not necessary, but > merely a matter of > efficiency. The actions specified in section 6.4.3 still work if they are > processed by an > address owner but have the added benefit that should there be two or more > routers with > priority 255, the tie-breaker based on primary IP address will stop them both > being in > active state simultaneously and continually. Perhaps 7.1 should be changed > (especially since > section 8.3.2 now appears to permit more than one router to have priority > 255) to be that a > router with local priority 255 MAY discard a received packet, rather than > MUST, so that > implementations can handle the situation of there being more than one router > configured with > priority 255 if they see that as beneficial, without that implementation then > being non- > conformant with the RFC. > > With many thanks, > > Quentin > > P.S. My understanding is the a Cisco VRRP implementation does not discard > received VRRP > packets when the local priority is 255 and uses the primary IP address > tie-breaker to ensure > that only one router is the active router; presumably that is non-compliant > with section > 7.1. > > On Wed, 2025-02-19 at 20:19 -0500, Acee Lindem wrote: >> Hi Quentin, et al, >> >> I think this Errata should be rejected. Trying to handled a misconfiguration >> rather than >> logging it as an error is not an errata change but something that could be >> proposed in a >> draft (along with any other such proposed changes). >> >> Thanks, >> Acee >> >>> On Feb 17, 2025, at 10:25, Quentin Armitage <quen...@armitage.org.uk> wrote: >>> >>> Further to the following, section 8.3.2 explicitly allows there to be more >>> than one VRRP >>> router to be configured with priority 255, by virtue of the use of SHOULD >>> rather than >>> MUST): >>> >>> 8.3.2. Recommendations Regarding Setting Priority Values >>> >>> A priority value of 255 designates a particular router as the "IPvX address >>> owner" for >>> the >>> VRID. VRRP Routers with priority 255 will, as soon as they start up, >>> preempt all lower- >>> priority routers. For a VRID, only a single VRRP Router on the link SHOULD >>> be configured >>> with priority 255. If multiple VRRP Routers advertising priority 255 are >>> detected, the >>> condition SHOULD be logged (subject to rate-limiting). >>> >>> With apologies for not including this in the original report. >>> >>> Quentin Armitage >>> >>> On Mon, 2025-02-17 at 06:05 -0800, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC9568, >>>> "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> https://www.rfc-editor.org/errata/eid8298 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Quentin Armitage <quen...@armitage.org.uk> >>>> >>>> Section: 7.1 >>>> >>>> Original Text >>>> ------------- >>>> 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. >>>> >>>> Corrected Text >>>> -------------- >>>> 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. >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". (If it is spam, it >>>> will be removed shortly by the RFC Production Center.) Please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party >>>> will log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC9568 (draft-ietf-rtgwg-vrrp-rfc5798bis-18) >>>> -------------------------------------- >>>> Title : Virtual Router Redundancy Protocol (VRRP) Version 3 >>>> for IPv4 and >>>> IPv6 >>>> Publication Date : April 2024 >>>> Author(s) : A. Lindem, A. Dogra >>>> Category : PROPOSED STANDARD >>>> Source : Routing Area Working Group >>>> Stream : IETF >>>> Verifying Party : IESG >>> >> > _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
