Internet-Draft VRRP HMAC Authentication July 2026
Cassen & Armitage Expires 28 January 2027 [Page]
Workgroup:
Routing Area Working Group
Internet-Draft:
draft-cassen-vrrp-auth-hmac-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
A. Cassen
Free
Q. Armitage
keepalived.org

An HMAC Authentication Extension for the Virtual Router Redundancy Protocol (VRRP)

Abstract

VRRP relies on a hop limit of 255 to prove that an advertisement came from the local link. That guard cannot apply when advertisements travel as multi-hop unicast across a routed or overlay network, as is common in cloud deployments, leaving the protocol open to off-segment injection and replay. The legacy VRRPv2 authentication types do not close this gap and were removed from later VRRP specifications. This document defines an authentication extension that appends an HMAC-SHA256 trailer and a time-based sequence number to VRRPv3 advertisements, authenticating the sender as a holder of the group key, protecting message integrity and bounding replay, for both IP address families. The extension is the primary defense where the hop-limit check cannot apply, and defense in depth for multicast and single-hop unicast, where that check remains in force.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 28 January 2027.

▲

Table of Contents

1. Introduction

The Virtual Router Redundancy Protocol [RFC9568] lets a group of routers share a virtual IP address so that a backup takes over when the active router fails. VRRP was designed as a first-hop protocol that runs on a single link, and its only built-in protection against a forged advertisement is the hop limit. An active router sends every advertisement with an IPv4 TTL or an IPv6 Hop Limit of 255, and a receiver drops any advertisement that does not arrive with that value. Because a router cannot raise a hop limit, an advertisement that arrives with 255 cannot have crossed a router, which proves it originated on the local link. This is the Generalized TTL Security Mechanism (GTSM) [RFC5082], and VRRPv3 leans on it entirely.

Unicast operation by itself does not lose that guard. A unicast VRRP specification that keeps the group on a shared link [I-D.abinabraham-vrrp-unicast] sends with a hop limit of 255 and rejects anything lower, so GTSM holds exactly as it does for multicast, and that specification explicitly excludes multi-hop operation. The gap opens in the deployments that go further. Implementations commonly run VRRP in cloud and virtualized networks where multicast is unavailable and the peers sit behind routers, so advertisements travel as unicast to a configured list of peers. They cross hops, arrive with a hop limit well below 255, and the receiver has to relax the check to accept them. The moment it does, the only guard VRRP had is gone. Anyone who can place a packet at the receiver with a spoofed source address can inject a forged advertisement that raises priority to demote the legitimate active router or sets priority 0 to force an immediate failover. Captured advertisements replay just as easily.

   Routed path: no multicast, TTL decremented en route

     ACTIVE  --- advert (VRID 51, prio 200) --->  BACKUP
   198.51.100.10                              192.0.2.10
       ^
       |  spoofed advert: src = 192.0.2.10 (a peer), prio 255
   ATTACKER
   203.0.113.9
Figure 1: Off-segment injection against multi-hop unicast VRRP

The same attack and defense apply over IPv6, where a deployment would use addresses such as 2001:db8::10 in place of those above.

The authentication types of earlier VRRP versions were removed as ineffective [RFC3768] and never carried into VRRPv3. In practice, unicast VRRP runs unauthenticated.

This document defines an authentication extension that closes the gap. It appends to each advertisement a trailer carrying an HMAC-SHA256 and a time-based sequence number. The HMAC authenticates the sender as a holder of the group key and protects integrity, the sequence number bounds replay, and both work the same way for unicast and multicast. For multi-hop unicast, where the hop-limit check cannot apply, the extension is the primary defense. For multicast and single-hop unicast it adds defense in depth against a compromised host on the local link.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Definitions

Trailer

The authentication trailer this document appends to an advertisement.

HMAC

The truncated HMAC-SHA256 carried in the trailer.

Group key

A symmetric key shared by every node of the virtual router group. A group holds one or more of them under distinct Key IDs (Section 9) and a sender signs with one.

Single-hop

Sender and receiver share a link. No router forwards the advertisement, so the hop limit arrives intact and GTSM holds.

Multi-hop

The advertisement crosses one or more routers, each of which decrements the hop limit, so GTSM cannot apply.

4. Applicability

The extension applies to VRRPv3 [RFC9568] advertisements, for both address families. A group either uses it on every node or on none, since a node that does not understand the trailer sees a longer packet and rejects it (Section 10). It authenticates advertisements only. It does not protect any other VRRP traffic and provides no confidentiality, which VRRP does not need because an advertisement carries routing intent rather than secret data.

Three deployment models differ in what the hop limit still proves, and the extension plays a different role in each.

multicast

The hop-limit check of [RFC9568] is mandatory and GTSM holds. The extension adds group-key-holder authentication, integrity and replay protection on top of it.

single-hop unicast

The group stays on a shared link and the hop-limit check of [I-D.abinabraham-vrrp-unicast] is equally mandatory. The extension plays the same defense-in-depth role.

multi-hop unicast

The advertisement crosses routers, the hop-limit check cannot succeed and is relaxed. The extension is the primary defense.

In multicast and single-hop unicast operation a receiver MUST keep enforcing the hop-limit check, since this extension complements GTSM and never replaces it.

Multi-hop operation itself is out of scope for this document. Hop-limit policy, source address selection, peer validation and routing behaviour for a routed VRRP deployment belong to a dedicated specification, and [I-D.abinabraham-vrrp-unicast] notes that multi-hop operation needs a security model of its own. This extension supplies the authentication and anti-replay component of that model. A multi-hop deployment or a future multi-hop specification SHOULD require it in enforce mode (Section 10) or an equivalent authenticated channel, since GTSM cannot apply there.

6. Sending Advertisements

To send an advertisement, a sender proceeds in this order:

  1. Build the VRRP message as usual and append the trailer.

  2. Set Ext Type to its scheme, Key ID to its active key (Section 9), Reserved to zero, and fill the sequence number as in Section 8.1.

  3. Compute the HMAC of Section 5.4 and write the result into the HMAC field.

  4. Compute and insert the VRRP checksum over the completed packet, on IPv4 over the VRRP message only and on IPv6 over the whole IP payload, typically by the sending stack.

The VRRP checksum comes last because on IPv6 it covers the trailer and therefore the HMAC just written. On IPv4 the checksum does not cover the trailer, and since the HMAC input reads the checksum field as zero either way, a stack that fills the IPv4 checksum before signing produces the same packet. A sender MUST allocate one Sequence Number and compute one HMAC per logical advertisement. In unicast mode every peer copy carries those same authentication fields, only the destination address and, on IPv6, the resulting checksum differ between copies [I-D.abinabraham-vrrp-unicast].

7. Receiving Advertisements

A receiver processes the trailer before any advertisement field reaches the VRRP state machine, so that a forged or stale packet never influences the election. Given an advertisement of expected VRRP message length L and an IP payload length P taken from the IP header:

  1. If P equals L, the advertisement carries no trailer. In receive-only and permissive modes (Section 10) the receiver accepts it and skips the remaining steps. In enforce mode the receiver drops it.

  2. Otherwise the trailer starts at offset L. If Ext Type identifies a scheme the receiver does not accept, or P does not equal L plus the trailer length that scheme defines, drop the advertisement as malformed. A payload shorter than L never reaches this step, the length checks of [RFC9568] already discard it.

  3. If Reserved is non-zero, drop the advertisement as malformed.

  4. In time mode (Section 8.2), compute the difference between the local clock and the Seconds field as in Section 8.1. If its magnitude exceeds the freshness window, drop the advertisement as stale. This test runs on an unauthenticated timestamp, so it only rejects and never grants trust.

  5. Look up the key identified by Key ID. If no such key exists, drop the advertisement.

  6. Recompute the HMAC of Section 5.4 over the advertisement as received and compare it to the HMAC field in constant time. On any mismatch, drop the advertisement. The VRRP checksum itself is validated under the normal rules of the address family, which on IPv6 the receiving stack typically does before delivery.

  7. Resolve the per-sender replay state (Section 8) and require the sequence to be newer than the stored high-water mark, compared as in Section 8.1. If it is not, drop the advertisement as a replay. Otherwise raise the high-water mark to this sequence and accept the advertisement.

The replay high-water mark advances only after the HMAC verifies in step 6, so forged or replayed data never moves it.

8. Anti-Replay

8.1. Sequence Number

The sequence number is an unsigned 64-bit value made of the 32-bit Seconds, the 16-bit Subseconds and the 16-bit Counter, most significant first. Seconds is the sender UTC time in seconds since the Unix epoch (1970-01-01T00:00:00Z), the same absolute reference on every node, which NTP distributes as UTC. Subseconds adds a binary fraction of a second, so the high 48 bits form a high-resolution timestamp and the Counter only separates advertisements that share one timestamp. A handful of Counter values suffice, because the 10 ms minimum advertisement interval caps a sender near a hundred advertisements per second, and the immediate advertisement a higher-priority router sends on seeing a lower-priority one (Section 6.4.3 of [RFC9568]) adds only a few.

A sender keeps the last sequence it used. On each transmission it loads its clock into Seconds and Subseconds with Counter zero, then sends that value if it exceeds the stored one, otherwise the stored value plus one. The increment raises Counter and carries into the timestamp on overflow, so the sequence advances even when the clock has not. The sequence does not move backward across a backward clock step, including a leap second, and needs no persistent storage as long as the clock advances across a restart. One exception recovers a corrected forward step in time mode, where the sender resets the sequence to the clock once the stored timestamp lies more than the freshness window (Section 8.2) ahead of it, since receivers already reject such advertisements as stale. Monotonic mode grows strictly, with no exception.

All three fields are unsigned and wrap, so all comparisons are modular rather than absolute. A receiver orders two sequences under serial number arithmetic [RFC1982] and forms the time-mode difference from the Seconds field as a signed 32-bit value modulo 2^32. A legitimate clock difference is far smaller than the 2^32-second wrap period, so the wrap is a non-event and the extension needs no epoch other than the Unix one.

8.2. Freshness Modes

The receiver enforces freshness in one of two modes.

time mode

The receiver keeps the freshness window from step 4 of Section 7 and also the per-sender high-water mark, so a valid but old capture is rejected both by absolute time and by the sequence. Time mode is the default and the security baseline of this document, and requires the group to keep its clocks in sync, for instance with NTP. The freshness window defaults to three times the configured advertisement interval with a floor of 5 seconds, and is configurable from 1 to 300 seconds. The receiver expires a high-water mark whose timestamp lies outside the window. This loses nothing, the window already rejects anything the mark would order, and it lets a sender that reset after a clock step recover.

monotonic mode

The receiver drops the freshness window and relies on the high-water mark alone, which removes the dependency on synchronized clocks at the cost of bounding freshness only against the last packet seen from each sender. The sequence is still clock-derived, so monotonic mode drops only the need for clocks to agree between nodes, not the need for a sender's clock to advance across a restart (Section 8.1). A sender that cannot guarantee that advance SHOULD persist its last sequence or use time mode, otherwise a restart can leave its advertisements rejected until the sequence climbs back above the stored high-water mark. A receiver MAY instead expire the high-water mark of a sender that has been silent for a configured time, so a restarted sender is treated as new, at the cost of a replay window as long as that time. Monotonic mode gives no inter-session replay protection once receiver state is lost and is unsuitable where that protection is required, unless sender and receiver persist their state.

8.3. Per-Sender State

Replay state is per sender, because each active router signs an independent sequence. For unicast, the receiver anchors the state on the configured peer whose address matches the packet source, and it drops a packet whose source is not a configured peer. For multicast there is no configured peer list, so the receiver keeps a small table of recent senders keyed by source address and evicts the least recently used entry when the table is full. The table is touched only after the HMAC verifies, so an attacker who floods forged source addresses cannot churn it. A handful of slots suffice, because several legitimate senders for one VRID appear only during a transient election.

9. Key Management and Rotation

A key is 32 to 64 octets of secret material with an identifier from 1 to 255. The 32-octet floor gives a 256-bit key, which keeps a 128-bit security margin against Grover's quantum search algorithm [GROVER], and 64 octets matches the HMAC-SHA256 block, so a longer key would only be pre-hashed. Every node in a group MUST hold the same keys under the same identifiers. Key material MUST be cryptographically random or derived by a key derivation function [RFC4086], a human-chosen passphrase of the minimum length does not carry the intended entropy. A key MUST NOT be reused by other protocols or unrelated groups.

A sender signs with one active key. A receiver verifies against whichever key the Key ID identifies, so a group can hold several keys at once. That overlap makes rotation safe without downtime. The operator installs the new key under a new identifier on every node, then moves the active key to the new identifier one node at a time, and once no node signs with the old identifier, removes that key everywhere. Signing and verifying keys never have to change in the same instant, matching the send and accept lifetimes of [RFC8177].

A key SHOULD be stored outside the VRRP configuration where the platform allows it, for instance as an encrypted system credential that the service manager unseals at start and exposes only to the running process. Keeping the secret off disk at rest and out of the configuration file limits its exposure.

10. Deployment and Migration

A node runs the extension in one of three modes, which differ only in whether the node sends a trailer and whether it tolerates the absence of one. A trailer that is present is always verified, and an advertisement whose trailer fails verification is always dropped, in every mode.

receive-only

The node holds the keys and verifies a present trailer, accepts an advertisement without a trailer, and sends without a trailer.

permissive

The node signs every advertisement it sends and still accepts one without a trailer.

enforce

The node signs every advertisement it sends and drops one without a valid trailer. This is the default, and a deployment that requires every advertisement to be authenticated MUST use it.

Because a receiver detects the trailer by length, a node that does not implement the extension, or that does not hold the keys yet, can drop the longer advertisements. A node therefore MUST NOT send a trailer before every peer can accept one, which is the state receive-only establishes. Migration takes three sweeps, and each sweep is hitless with no timing constraint between nodes. First the operator configures the keys with receive-only on every node, which changes nothing on the wire while every node becomes able to verify. Then the operator switches every node to permissive, and signing starts against peers that already accept trailers. Once trailers verify in both directions everywhere, the operator switches every node to enforce, after which untrailered advertisements are dropped.

11. Security Considerations

11.1. Threat Model

The extension targets an adversary who can place a packet at a receiver with a spoofed source address but does not hold the group key. For unicast this includes any party that can reach the receiver across the routed or overlay network, such as another tenant in a shared fabric or a compromised host in a different subnet. For multicast it includes a host on the local link. The adversary may inject forged advertisements and replay captured ones, aiming to seize the virtual address by advertising a high priority, to force a failover with priority 0, or to flap the group.

11.2. What the Extension Provides

A valid HMAC proves that the sender holds the group key and that the VRRP message and the bound fields arrived intact. The pseudo-header (Section 5.3) stops a captured trailer from being spliced onto another instance or accepted from another source. The sequence number and, in time mode, the freshness window reject replays. Against the off-segment unicast attacker the extension restores the protection that the hop-limit check gave on a shared link, and it does so whether or not that check still applies.

11.3. Group Key

The scheme uses one symmetric key per group, so every member can impersonate every other member. It defends the group perimeter, not one member against another, which matches the VRRP trust model where all routers in a group are mutually trusting. A compromised node exposes the key for the whole group, and the response is to rotate the key out as in Section 9.

11.4. Migration Exposure

The receive-only and permissive modes accept advertisements that carry no trailer, so while any node runs one of them, an attacker who can place a packet at that node injects an unsigned advertisement exactly as before the extension. The protections of this document only hold once every node in the group enforces. Migration modes exist to sequence a rollout, not to operate in, so an operator SHOULD bound the time a group spends outside enforce mode.

11.5. Denial of Service

A receiver computes at most one HMAC per packet that passes the cheap length check and, in time mode, the freshness window, so replayed captures are shed before the digest. Monotonic mode keeps no window, so there every well-formed packet under a known key reaches the digest. A flood that clears these checks still forces one HMAC per packet, so an operator SHOULD keep the usual rate limiting and network-layer filtering in place.

11.6. Clock Dependence

Time mode drops advertisements when the sender and receiver clocks differ by more than the freshness window, so a group that uses it depends on time synchronization for availability. Where that is not assured, monotonic mode (Section 8.2) removes the dependency on clock agreement between nodes. An operator SHOULD secure the time synchronization itself, since stepping a sender or receiver clock becomes an availability attack.

11.7. State Loss and Replay

Replay state is volatile. After a receiver restart, time mode accepts a valid capture once if it still lies inside the freshness window, so the replay protection of this document is bounded by the window rather than absolute. Monotonic mode accepts a valid capture of any age once after state loss. After a sender recovers from a forward clock step (Section 8.1), the advertisements signed during the incident stay replayable until their timestamps leave the window.

11.8. Cryptographic Strength

HMAC-SHA256 truncated to 128 bits gives 128-bit forgery resistance, which is appropriate for a per-packet HMAC on a control protocol. The 256-bit minimum key preserves a 128-bit margin under Grover's quantum search algorithm [GROVER]. The receiver compares the HMAC in constant time so that the comparison leaks no timing information about the expected HMAC.

11.9. Relationship to Other Mechanisms

Compared with IPsec and the IP Authentication Header [RFC4302], the extension avoids IKE and security-association state, works identically for multicast and unicast, and rotates keys without downtime, at the cost of being specific to VRRP and using a single group key. For a routed pair, pairwise IPsec with IKEv2 additionally authenticates individual peers and automates rekeying, properties this extension trades for deployment simplicity.

12. IANA Considerations

This document requests a new registry, "VRRP Authentication Extension Types", for the 8-bit Ext Type field of Figure 2. The initial contents are:

Table 1
Value Description Trailer Length Reference
0 Reserved   This document
1 HMAC-SHA256, truncated to 128 bits 28 octets This document
2-255 Unassigned    

New assignments are made under the Specification Required policy of [RFC8126] and MUST define the total trailer length, which receivers use for detection (Section 7). An Ext Type identifies one complete construction, algorithm, truncation and trailer length. Constructions that differ in any of these need distinct values, so the length always follows from the type. The Key ID field of the trailer is a local selector and is not managed by IANA.

13. References

13.1. Normative References

[RFC1982]
Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, , <https://www.rfc-editor.org/rfc/rfc1982>.
[RFC2104]
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, , <https://www.rfc-editor.org/rfc/rfc2104>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6234]
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, , <https://www.rfc-editor.org/rfc/rfc6234>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9568]
Lindem, A. and A. Dogra, "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 9568, DOI 10.17487/RFC9568, , <https://www.rfc-editor.org/rfc/rfc9568>.

13.2. Informative References

[GROVER]
Grover, L. K., "A Fast Quantum Mechanical Algorithm for Database Search", Proceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC '96), , <https://doi.org/10.1145/237814.237866>.
[I-D.abinabraham-vrrp-unicast]
Dogra, A., Abraham, A. M., and S. Krishnamurthy, "Unicast Support for the Virtual Router Redundancy Protocol (VRRP)", Work in Progress, Internet-Draft, draft-abinabraham-vrrp-unicast-01, , <https://datatracker.ietf.org/doc/html/draft-abinabraham-vrrp-unicast-01>.
[RFC3768]
Hinden, R., Ed., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, DOI 10.17487/RFC3768, , <https://www.rfc-editor.org/rfc/rfc3768>.
[RFC4086]
Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, , <https://www.rfc-editor.org/rfc/rfc4086>.
[RFC4302]
Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, , <https://www.rfc-editor.org/rfc/rfc4302>.
[RFC5082]
Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, , <https://www.rfc-editor.org/rfc/rfc5082>.
[RFC8177]
Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, , <https://www.rfc-editor.org/rfc/rfc8177>.

Appendix A. Test Vectors

Both vectors use VRRPv3, VRID 51, priority 200, a one-second advertisement interval and a single virtual address, signed with Ext Type 1 under Key ID 1 and this 32-octet key:

  00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
  10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

The trailer carries Seconds 0x68000000, Subseconds 0x8000 and Counter 0. The dumps show the payload as transmitted, so the Checksum field at octets 6 and 7 and the HMAC in the last 16 octets carry their final values, and both are read as zero in the HMAC input.

A.1. IPv4

The sender 198.51.100.10 advertises the virtual address 192.0.2.100. The pseudo-header of Section 5.4 is:

  04 03 33 00 c6 33 64 0a 00 00 00 00 00 00 00 00
  00 00 00 00

The full HMAC-SHA256 before truncation is:

  1b84bc4e8e43892dc6d98448f8ee2265
  f674824d1bfd1c6e62aa1b5f4312fe4a

The IP payload as transmitted, VRRP message then trailer, is:

  31 33 c8 01 00 64 44 02 c0 00 02 64 01 01 00 00
  68 00 00 00 80 00 00 00 1b 84 bc 4e 8e 43 89 2d
  c6 d9 84 48 f8 ee 22 65

The checksum 0x4402 covers the message only [RFC9568], without a pseudo-header, and is therefore identical in every unicast peer copy.

A.2. IPv6

The sender fe80::10 addresses the peer fe80::20 and advertises the virtual address fe80::100, link-local as [RFC9568] requires. The pseudo-header of Section 5.4 is:

  06 03 33 00 fe 80 00 00 00 00 00 00 00 00 00 00
  00 00 00 10

The full HMAC-SHA256 before truncation is:

  c8c56146ebfd66ee10ec4d8186461b78
  016459dfdb722df2300edca011646494

The IP payload as transmitted is:

  31 33 c8 01 00 64 a2 e9 fe 80 00 00 00 00 00 00
  00 00 00 00 00 00 01 00 01 01 00 00 68 00 00 00
  80 00 00 00 c8 c5 61 46 eb fd 66 ee 10 ec 4d 81
  86 46 1b 78

The transport checksum 0xa2e9 covers the whole payload, trailer and HMAC included, which is why it is computed last and read as zero in the HMAC input.

Appendix B. Acknowledgements

This extension grew out of the keepalived project. Its design matured over several iterations there, shaped by reports from operators who run keepalived at scale and by seeing how widely VRRP now runs as unicast in cloud and virtualized networks. The authors thank the keepalived users and contributors whose feedback, testing, and field experience guided the work.

The authors thank Aditya Dogra for his thorough review, which uncovered real defects and sharpened both the mechanism and this document.

Authors' Addresses

Alexandre Cassen
Free / keepalived.org
Quentin Armitage
keepalived.org