Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6LabN Consulting, L.L.C.301 Midenhall WayCaryNC27513United States of Americaacee.ietf@gmail.comCisco SystemsSarjapur Outer Ring RoadBangaloreKarnataka560103Indiaaddogra@cisco.com
Routing Area
VRRP
This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP)
for IPv4 and IPv6. It obsoletes RFC 5798, which previously specified VRRP (version 3).
RFC 5798 obsoleted RFC 3768, which specified VRRP (version 2) for IPv4.
VRRP specifies an election protocol that dynamically assigns responsibility for a
Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router
controlling the IPv4 or IPv6 address(es) associated with a Virtual
Router is called the Active Router, and it forwards packets routed to these
IPv4 or IPv6 addresses. Active Routers are configured with
virtual IPv4 or IPv6 addresses, and Backup Routers infer the
address family of the virtual addresses being advertised based on the
IP protocol version. Within a VRRP Router, the Virtual Routers in
each of the IPv4 and IPv6 address families are independent of one another
and always treated as separate Virtual Router instances.
The election process provides dynamic
failover in the forwarding responsibility should the Active Router become
unavailable. For IPv4, the advantage gained from using VRRP is a
higher-availability default path without requiring configuration of
dynamic routing or router discovery protocols on every end-host. For
IPv6, the advantage gained from using VRRP for IPv6 is a quicker
switchover to Backup Routers than can be obtained with standard IPv6
Neighbor Discovery mechanisms.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Differences from RFC 5798
. A Note on Terminology
. IPv4
. IPv6
. Requirements Language
. Scope
. Definitions
. Required Features
. IPvX Address Backup
. Preferred Path Indication
. Minimization of Unnecessary Service Disruptions
. Efficient Operation over Extended LANs
. Sub-second Operation for IPv4 and IPv6
. VRRP Overview
. Sample VRRP Networks
. Sample VRRP Network 1
. Sample VRRP Network 2
. Protocol
. VRRP Packet Format
. IPv4 Field Descriptions
. Source Address
. Destination Address
. TTL
. Protocol
. IPv6 Field Descriptions
. Source Address
. Destination Address
. Hop Limit
. Next Header
. VRRP Field Descriptions
. Version
. Type
. Virtual Rtr ID (VRID)
. Priority
. IPvX Addr Count
. Reserve
. Maximum Advertisement Interval (Max Advertise Interval)
Introduction
This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP)
for IPv4 and IPv6. It obsoletes , which previously
specified VRRP (version 3). obsoleted ,
which specified VRRP (version 2) for IPv4.
VRRP specifies an election protocol that dynamically
assigns responsibility for a Virtual Router
(refer to ) to one of the VRRP
Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6
address(es) associated with a Virtual Router is called the Active Router,
and it forwards packets routed to these IPv4 or IPv6 addresses (except for
packets addressed to these addresses as described in ).
VRRP Active Routers are configured with virtual IPv4 or IPv6 addresses,
and Backup Routers infer the address family of the virtual
addresses being advertised based on the IP protocol version. Within a
VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address
families are independent of one another
and always treated as separate Virtual Router instances. The
election process provides dynamic failover in the forwarding
responsibility should the Active Router become unavailable.
VRRP provides a function similar to the proprietary protocols Hot Standby Router Protocol (HSRP)
and IP Standby Protocol .
Differences from RFC 5798
The following changes have been made from :
The VRRP terminology has been updated to conform to inclusive language
guidelines for IETF technologies.
The IETF has designated the National Institute of Standards and Technology (NIST)
document "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards"
for its inclusive language guidelines.
The term for the VRRP Router assuming forwarding responsibility has been changed
to "Active Router" to be consistent with IETF inclusive terminology. Additionally,
inconsistencies in the terminology of for both "Active Router" and "Backup Router"
were corrected. Additionally, the undesirable term for attracting and dropping
unreachable packets has been changed.
Errata pertaining to the state machines in were
corrected.
The checksum calculation in has been clarified to specify
precisely what is included and that it does not include the pseudo-header for IPv4.
When a VRRP advertisement is received from a lower priority VRRP Router, the Active
VRRP Router will immediately send a VRRP advertisement to assure learning bridges
will bridge the packets to the correct Ethernet segment
(refer to ).
Appendices describing operation over legacy technologies (Fiber Distributed Data Interface (FDDI), Token
Ring, and ATM LAN Emulation) were removed.
A recommendation was added indicating that IPv6 Unsolicited Neighbor Advertisements
SHOULD be accepted by the Active and Backup Routers ().
Checking that the Maximum Advertisement Intervals match is recommended, although this will
not result in the VRRP packet being dropped ().
Miscellaneous editorial changes were made for readability.
The IANA Considerations section was augmented to include all the IPv4/IPv6
multicast address allocations and Ethernet Media Access Control (MAC) address allocations.
A Note on Terminology
This document discusses both IPv4 and IPv6 operations, and with
respect to the VRRP protocol, many of the descriptions and procedures
are common. In this document, it would be less verbose to be able to
refer to "IP" to mean either "IPv4 or IPv6". However, historically,
the term "IP" often refers to IPv4. For this reason, in this
specification, the term "IPvX" (where X is 4 or 6) is introduced to
mean either "IPv4" or "IPv6". In this text, where the IP version
matters, the appropriate term is used, and the use of the term "IP" is
avoided.
IPv4
There are a number of methods that an IPv4 end-host can use to
determine its first-hop router for a particular IPv4 destination.
These include running (or snooping) a dynamic routing protocol such
as Routing Information Protocol (RIP) or OSPF version 2
, running an ICMP router discovery client
, running DHCPv4 , or using a
statically configured default route.
Running a dynamic routing protocol on every end-host may
not be feasible for a number of reasons, including administrative
overhead, processing overhead, security issues, or the lack of an
implementation for a particular platform. Neighbor or router discovery
protocols may require active participation by all hosts on a network,
requiring large timer values to reduce protocol overhead associated
with the protocol packet processing for each host. This can result in
a significant delay in the detection of an unreachable router, and
such a delay may introduce unacceptably long periods of unreachability for the
default route.
The use of a manually configured default route (either via a static route
or DHCPv4) is quite popular since it minimizes configuration and
processing overhead on the end-host and
is supported by virtually every IPv4 implementation.
However, this creates a single point of failure. Loss of the default
router results in a catastrophic event, isolating all end-hosts that
are unable to detect an available alternate path.
The Virtual Router Redundancy Protocol (VRRP) is designed to
eliminate the single point of failure inherent in a network utilizing
default routing. VRRP specifies an election protocol that
dynamically assigns responsibility for a Virtual Router to one of the
VRRP Routers on a LAN. The VRRP Router controlling the IPv4
address(es) associated with a Virtual Router is called the Active Router and
forwards packets sent to these IPv4 addresses. The election process
provides dynamic failover of the forwarding responsibility should the
Active Router become unavailable. Any of the Virtual Router's IPv4
addresses on a LAN can then be used as the default first-hop
router by end-hosts. The advantage gained from using VRRP is a
higher availability default path without requiring configuration of
dynamic routing or a router discovery protocol on every end-host.
IPv6
IPv6 hosts on a LAN will usually learn about one or more default
routers by receiving Router Advertisements sent using the IPv6
Neighbor Discovery (ND) protocol .
The Router Advertisements are periodically multicast
at a rate such that the hosts can take more
than 10 seconds to learn the default routers on a LAN.
They are not sent frequently enough to rely on the absence
of the Router Advertisement to detect router failures.
The ND protocol includes a mechanism called Neighbor
Unreachability Detection to detect the failure of a neighbor node
(router or host) or the forwarding path to a neighbor. This is done
by sending unicast ND Neighbor Solicitation messages to the neighbor
node. To reduce the overhead of sending Neighbor Solicitations, they
are only sent to neighbors to which the node is actively sending
traffic and only after there has been no positive indication that the
router is up for a period of time. Using the default parameters in
ND, it can take a host more than 10 seconds to learn that a router is
unreachable before it will switch to another default router. This
delay would be very noticeable to users and cause some transport
protocol implementations to time out.
While the Neighbor Unreachability Detection could be made quicker by
configuring the timer intervals to be more aggressive (note that the current
lower limit for this is 5 seconds), this would have the downside of
significantly increasing the overhead of ND traffic, especially when
there are many hosts all trying to determine the reachability of one
or more routers.
The Virtual Router Redundancy Protocol for IPv6 provides a much
faster switchover to an alternate default router than can be obtained
using standard ND procedures. Using VRRP, a Backup Router can take
over for a failed default router in around three seconds (using VRRP
default parameters). This is done without any interaction with the
hosts and a minimum amount of VRRP traffic.
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
when, and only when, they appear in all capitals, as shown here.
Scope
The remainder of this document describes the features, design goals,
and theory of operation of VRRP. The message formats, protocol
processing rules, and state machine that guarantee convergence to a
single Active Router are presented. Finally, operational
issues related to MAC address mapping, handling of ARP messages,
generation of ICMP redirect messages, and security issues are
addressed.
Definitions
VRRP Router
A router running the Virtual Router
Redundancy Protocol. It may participate as
one or more Virtual Routers.
Virtual Router
An abstract object managed by VRRP that acts
as a default router for hosts on a shared
LAN. It consists of a Virtual Router
Identifier and either a set of associated
IPv4 addresses or a set of associated IPv6
addresses across a common LAN. A VRRP Router
can serve as a Backup Router for one or more
Virtual Routers.
Virtual Router Identifier
An integer value (1-255) identifying an instance
of a Virtual Router on a LAN. Also referred by its
acronym, VRID.
Virtual Router MAC Address
The multicast Ethernet MAC address used for
VRRP advertisements for a VRID. Refer to
.
IP Address Owner
The VRRP Router that has the Virtual Router's
IPvX address(es) as real interface
address(es). This is the router that, when
up, will respond to packets addressed to one
of these IPvX addresses for ICMP pings, TCP
connection requests, etc.
Primary IP Address
In IPv4, an IPv4 address selected from the
set of real interface addresses. One
possible selection algorithm is to always
select the first address. In IPv4, VRRP
advertisements are always sent using the
primary IPv4 address as the source of the
IPv4 packet. In IPv6, the link-local address
of the interface over which the packet is
transmitted is used.
Forwarding Responsibility
The responsibility for forwarding packets sent to
the IPvX address(es) associated with the
Virtual Router. This includes receiving packets
sent to the Virtual Router MAC address, forwarding these
packets based on the local Routing Information Base (RIB) /
Forwarding Information Base (FIB), answering
ARP requests for the IPv4 address(es), and answering ND
requests for the IPv6 address(es).
Active Router
The VRRP Router that is assuming the
responsibility of forwarding packets sent to
the IPvX address(es) associated with the
Virtual Router, answering ARP requests
for the IPv4 address(es), and answering ND
requests for the IPv6 address(es). Note that
if the IPvX address owner is available, then
it will always be the Active Router.
Backup Router(s)
The set of VRRP Routers available to assume
forwarding responsibility for a Virtual
Router should the current Active Router fail.
Drop Route
A route installed in the Routing Information Base (RIB) that
will result in traffic with a destination address that matches
the route to be dropped.
Required Features
This section describes the set of features that were considered
mandatory and that guided the design of VRRP.
IPvX Address Backup
Backup of an IPvX address or addresses is the primary function of
VRRP. When providing election of an Active Router and the
additional functionality described below, the protocol should
strive to:
minimize the duration of unreachability,
minimize the steady-state bandwidth overhead and processing
complexity,
function over a wide variety of multiaccess LAN technologies
capable of supporting IPvX traffic,
allow multiple Virtual Routers on a network for load-balancing, and
support multiple logical IPvX subnets on a single LAN segment.
Preferred Path Indication
A simple model of Active Router election among a set of redundant routers is
to treat each router with equal preference and claim victory after
converging to any router as the Active Router. However, there are likely to be
many environments where there is a distinct preference (or range of
preferences) among the set of redundant routers. For example, this
preference may be based upon access link cost or speed, router
performance or reliability, or other policy considerations. The
protocol should allow the expression of this relative path preference
in an intuitive manner and guarantee Active Router convergence to the most
preferred Virtual Router currently available.
Minimization of Unnecessary Service Disruptions
Once Active Router election has been performed, any unnecessary transition
between Active and Backup Routers can result in a disruption of
service. The protocol should ensure that, after Active Router election, no
state transition is triggered by any Backup Router of equal or lower
preference as long as the Active Router continues to function properly.
Some environments may find it beneficial to avoid the state
transition triggered when a router that is preferred over the current
Active Router becomes available. It may be useful to support an override of
the immediate restoration to the preferred path.
Efficient Operation over Extended LANs
Sending IPvX packets, i.e., sending either IPv4 or IPv6, on a
multiaccess LAN requires mapping from an IPvX address to a MAC
address. The use of the Virtual Router MAC address in an extended
LAN employing learning bridges can have a significant effect on the
bandwidth overhead of packets sent to the Virtual Router. If the
Virtual Router MAC address is never used as the source address in a
link-level frame, then the MAC address location is never learned,
resulting in flooding of all packets sent to the Virtual Router. To
improve the efficiency in this environment, the protocol should do the
following:
Use the Virtual Router MAC address as the source in a packet sent
by the Active Router to trigger MAC learning.
Trigger a message immediately after transitioning to the
Active Router to update MAC learning.
Trigger periodic messages from the Active Router to
maintain the MAC address cache.
Sub-second Operation for IPv4 and IPv6
Sub-second detection of Active Router failure is needed in both
IPv4 and IPv6 environments. Earlier work proposed that sub-second
operation was for IPv6, and this specification leverages that earlier
approach for both IPv4 and IPv6.
One possible problematic scenario that may occur when using a small
Advertisement_Interval (refer to ) is
when a VRRP Router is generating more packets than it can transmit, and a queue
builds up on the VRRP Router. When this occurs, it is possible that packets being
transmitted onto the VRRP-protected LAN could see a larger queueing
delay than the smallest Advertisement_Interval. In this case,
the Active_Down_Interval (refer to ) may be small
enough that normal queuing
delays might cause a Backup Router to conclude that the Active Router is down
and, hence, promote itself to Active Router. Very shortly afterwards, the
delayed VRRP packets from the original Active Router cause the VRRP Router to switch back to Backup
Router. Furthermore, this process can repeat many times per second,
causing a significant disruption of traffic. To mitigate this problem,
giving VRRP packets priority on egress interface queues should be considered.
If the Active Router observes that this is occurring, it SHOULD log the problem
(subject to rate-limiting).
VRRP Overview
VRRP specifies an election protocol to provide the Virtual Router
function described earlier. All protocol messaging is performed
using either IPv4 or IPv6 multicast datagrams. Thus, the protocol can
operate over a variety of multiaccess LAN technologies supporting
IPvX multicast. Each link of a VRRP Virtual Router has a single
well-known MAC address allocated to it. This document currently only
details the mapping to networks using an IEEE 802 48-bit MAC
address. The Virtual Router MAC address is used as the source in all
periodic VRRP messages sent by the Active Router to enable MAC
learning by Layer 2 (L2) bridges on an extended LAN.
A Virtual Router is defined by its Virtual Router Identifier (VRID)
and a set of either IPv4 or IPv6 address(es). A VRRP Router may
associate a Virtual Router with its real address on an interface.
The scope of each Virtual Router is restricted to a single LAN. A
VRRP Router may be configured with additional Virtual Router mappings
and priority for Virtual Routers it is willing to back up. The
mapping between the VRID and its IPvX address(es) must be coordinated
among all VRRP Routers on a LAN.
There is no restriction against reusing a VRID with a different
address mapping on different LANs, nor is there a restriction against
using the same VRID number for a set of IPv4 addresses and a set of
IPv6 addresses. However, these are two different Virtual Routers.
To minimize network traffic, only the Active Router for each Virtual Router
sends periodic VRRP Advertisement messages. A Backup Router will not
attempt to preempt the Active Router unless the Backup Router
has a higher priority. This
eliminates service disruption unless a more preferred path becomes
available. It's also possible to administratively prohibit Active Router
preemption attempts. The only exception is that a VRRP Router will
always become the Active Router for any Virtual Router associated with
address(es) it owns. If the Active Router becomes unavailable, then the
highest-priority Backup Router will transition to the Active Router
after a short delay, providing a controlled transition of Virtual Router
responsibility with minimal service interruption.
The VRRP protocol design provides rapid transition from the Backup Router to
the Active Router to minimize service interruption and incorporates
optimizations that reduce protocol complexity while guaranteeing
controlled Active Router transition for typical operational scenarios. These
optimizations result in an election protocol with minimal runtime
state requirements, minimal active protocol states, and a single
message type and sender. The typical operational scenarios are
defined to be two redundant routers and/or distinct path preferences
for each router. A side effect when these assumptions are violated,
i.e., more than two redundant paths with equal preference, is
that duplicate packets may be forwarded for a brief period during
Active Router election. However, the typical scenario assumptions are
likely to cover the vast majority of deployments, loss of the Active
Router is infrequent, and the expected duration for Active Router election
convergence is quite small (< 4 seconds when using the default
Advertisement_Interval and configurable to < 1/25 second). Thus,
the VRRP optimizations represent significant simplifications in
the protocol design while incurring an insignificant probability of
brief network disruption.
Sample VRRP NetworksSample VRRP Network 1
The following figure shows a simple network with two VRRP Routers
implementing one Virtual Router.
Sample VRRP Network 1
+-----------+ +-----------+
| Router-1 | | Router-2 |
|(AR VRID=1)| |(BR VRID=1)|
| | | |
VRID=1 +-----------+ +-----------+
IPvX A------>* *<---------IPvX B
| |
| |
-------------+------------+--+-----------+-----------+-----------+
^ ^ ^ ^
| | | |
Default Router | | | |
IPvX Addresses ---> (IPvX A) (IPvX A) (IPvX A) (IPvX A)
| | | |
IPvX H1->* IPvX H2->* IPvX H3->* IPvX H4->*
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
Legend:
--+---+---+-- = Ethernet
H = Host computer
AR = Active Router
BR = Backup Router
* = IPvX Address: X is 4 everywhere in IPv4 case
X is 6 everywhere in IPv6 case
(IPvX) = Default Router for hosts
In the IPv4 case, i.e., IPvX is IPv4 everywhere in the figure,
each router is permanently assigned an IPv4 address on the LAN
interface (Router-1 is assigned IPv4 A and Router-2 is assigned IPv4 B), and
each host installs a default route (learned through DHCPv4 or via a
configured static route) through one of the routers
(in this example, they all use Router-1's IPv4 A).
In the IPv6 case, i.e., IPvX is IPv6 everywhere in the figure, each router has its own
link-local IPv6 address on the LAN interface and a link-local
IPv6 address per VRID that is shared with the other routers that serve the same VRID.
Each host learns a default route from Router
Advertisements through one of the routers (in this example, they all
use Router-1's IPv6 Link-Local A).
In an IPv4 VRRP environment, each router supports reception and transmission for
the exact same IPv4 address. Router-1 is said to be the IPv4
address owner of IPv4 A, and Router-2 is the IPv4 address owner of
IPv4 B. A Virtual Router is then defined by associating a unique
identifier (the VRID) with the address owned by Router-1.
In an IPv6 VRRP environment, each router will support transmission and
reception for the IPv6 addresses associated with the VRID.
Router-1 is said to be the IPv6 address owner
of IPv6 A, and Router-2 is the IPv6 address owner of IPv6 B. A Virtual
Router is then defined by associating a unique identifier (the
VRID) with the address owned by Router-1.
Finally, in both the IPv4 and IPv6 cases, the VRRP protocol manages
Virtual Router failover to a Backup Router.
The IPvX example above shows a Virtual Router configured to cover the
IPvX address owned by Router-1 (VRID=1, IPvX_Address=A). When VRRP is
enabled on Router-1 for VRID=1, it will assert itself as the Active Router, with
priority = 255, since it is the IPvX address owner for the Virtual
Router IPvX address. When VRRP is enabled on Router-2 for VRID=1, it will
transition to the Backup Router, with priority = 100 (the default priority is
100), since it is not the IPvX address owner. If Router-1 should fail,
then the VRRP protocol will transition Router-2 to the Active Router, temporarily
taking over forwarding responsibility for IPvX A to provide
uninterrupted service to the hosts.
Note that in both cases in this example, IPvX B is not backed up and it
is only used by Router-2 as its interface address. In order to back up
IPvX B, a second Virtual Router must be configured. This is shown in
the next section.
Sample VRRP Network 2
The following figure shows a configuration with two Virtual Routers
with the hosts splitting their traffic between them.
Sample VRRP Network 2
+-----------+ +-----------+
| Router-1 | | Router-2 |
|(AR VRID=1)| |(BR VRID=1)|
|(BR VRID=2)| |(AR VRID=2)|
VRID=1 +-----------+ +-----------+ VRID=2
IPvX A ----->* *<---------- IPvX B
| |
| |
----------+-------------+-+-----------+-----------+-----------+
^ ^ ^ ^
| | | |
Default Router | | | |
IPvX Addresses ---> (IPvX A) (IPvX A) (IPvX B) (IPvX B)
| | | |
IPvX H1->* IPvX H2->* IPvX H3->* IPvX H4->*
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
Legend:
---+---+---+-- = Ethernet
H = Host computer
AR = Active Router
BR = Backup Router
* = IPvX Address: X is 4 everywhere in IPv4 case
X is 6 everywhere in IPv6 case
(IPvX) = Default Router for hosts
In the IPv4 example above, i.e., IPvX is IPv4 everywhere in the
figure, half of the hosts have configured a static default route through
Router-1's IPv4 A, and half are using Router-2's IPv4 B. The configuration
of Virtual Router VRID=1 is exactly the same as in the first example
(see ), and a second Virtual Router has been added to
cover the IPv4 address owned by Router-2 (VRID=2, IPv4_Address=B). In
this case, Router-2 will assert itself as the Active Router for VRID=2, while Router-1
will act as a Backup Router. This scenario demonstrates a deployment
providing load-splitting when both routers are available, while
providing full redundancy for robustness.
In the IPv6 example above, i.e., IPvX is IPv6 everywhere in the
figure, half of the hosts are using a default route through
Router-1's IPv6 A, and half are using Router-2's IPv6 B. The configuration
of Virtual Router VRID=1 is exactly the same as in the first example
(see ), and a second Virtual Router has been added to
cover the IPv6 address owned by Router-2 (VRID=2, IPv6_Address=B). In
this case, Router-2 will assert itself as the Active Router for VRID=2, while Router-1
will act as a Backup Router. This scenario demonstrates a deployment
providing load-splitting when both routers are available while
providing full redundancy for robustness.
Note that the details of load-balancing are out of scope of this
document. However, in a case where the servers need different
weights, it may not make sense to rely on Router Advertisements alone
to balance the host traffic between the routers .
Protocol
The purpose of the VRRP Advertisement is to communicate to all VRRP Routers
the priority, Maximum Advertisement Interval, and IPvX addresses of the Active Router
associated with the VRID.
When VRRP is protecting an IPv4 address, VRRP packets are sent
encapsulated in IPv4 packets. They are sent to the IPv4 multicast
address assigned to VRRP.
When VRRP is protecting an IPv6 address, VRRP packets are sent
encapsulated in IPv6 packets. They are sent to the IPv6 multicast
address assigned to VRRP.
VRRP Packet Format
This section defines the format of the VRRP packet and the relevant
fields in the IPvX header (in conjunction with the address family).
IPv4/IPv6 VRRP Advertisement Packet Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Fields or IPv6 Fields |
... ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority |IPvX Addr Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserve| Max Advertise Interval| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPvX Address(es) |
+ +
+ +
+ +
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Field DescriptionsSource Address
This is the primary IPv4 address of the interface from which the packet is being
sent.
Destination Address
The IPv4 multicast address as assigned by the IANA for VRRP is:
224.0.0.18
This is a link-local scope multicast address. Routers MUST NOT
forward a datagram with this destination address, regardless of its
TTL.
TTL
The TTL MUST be set to 255. A VRRP Router receiving a packet with
the TTL not equal to 255 MUST discard the packet .
Protocol
The IPv4 protocol number assigned by the IANA for VRRP is 112
(decimal).
IPv6 Field DescriptionsSource Address
This is the IPv6 link-local address of the interface from which the packet is
being sent.
Destination Address
The IPv6 multicast address assigned by the IANA for VRRP is:
ff02:0:0:0:0:0:0:12
This is a link-local scope multicast address. Routers MUST NOT
forward a datagram with this destination address, regardless of its
Hop Limit.
Hop Limit
The Hop Limit MUST be set to 255. A VRRP Router receiving a packet
with the Hop Limit not equal to 255 MUST discard the
packet .
Next Header
The IPv6 Next Header protocol assigned by the IANA for VRRP is 112
(decimal).
VRRP Field DescriptionsVersion
The Version field specifies the VRRP protocol version of this packet.
This document defines version 3.
Type
The Type field specifies the type of this VRRP packet. The only
packet type defined in this version of the protocol is:
1
- ADVERTISEMENT
A packet with unknown type MUST be discarded.
Virtual Rtr ID (VRID)
The Virtual Rtr ID field identifies the Virtual Router for which this
packet is reporting status.
Priority
The Priority field specifies sending the VRRP Router's priority for
the Virtual Router. Higher values indicate higher priority. This field
is an 8-bit unsigned integer field.
The priority value for the VRRP Router that owns the IPvX address
associated with the Virtual Router MUST be 255 (decimal).
VRRP Routers backing up a Virtual Router MUST use priority values
between 1-254 (decimal). The default priority value for VRRP Routers
backing up a Virtual Router is 100 (decimal). Refer to
for recommendations on setting the priority.
The priority value zero (0) has special meaning, indicating that the
current Active Router has stopped participating in VRRP. This is used to
trigger Backup Routers to quickly transition to the Active Router without having
to wait for the current Active_Down_Interval (refer to ).
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.
Reserve
The Reserve field MUST be set to zero on transmission and ignored on
reception.
Maximum Advertisement Interval (Max Advertise Interval)
The Max Advertise Interval is a 12-bit field that indicates
the time interval (in centiseconds) between advertisements. The
default is 100 centiseconds (1 second).
Note that higher-priority Active Routers with slower transmission
rates than their Backup Routers are unstable. This is because
lower-priority Backup Routers configured to faster rates could join the LAN and
decide they should be Active Routers before they have heard anything from
the higher-priority Active Router with a slower rate. When this happens, it
is temporary, i.e., once the lower-priority node does hear from the higher-priority
Active Router, it will relinquish Active Router status.
Checksum
The Checksum field is used to detect data corruption in the VRRP
message.
For both the IPv4 and IPv6 address families, the checksum is the
16-bit one's complement of the one's complement sum of the VRRP
message. For computing the checksum,
the Checksum field is set to zero. See for more details.
For the IPv4 address family, the checksum calculation only includes the
VRRP message starting with the Version field and ending after the last
IPv4 address (refer to ).
For the IPv6 address family, the checksum calculation also includes
a prepended "pseudo-header", as defined in .
The Next Header field in the "pseudo-header" should be set to 112 (decimal)
for VRRP.
IPvX Address(es)
This refers to one or more IPvX addresses associated with the Virtual
Router. The number of addresses included is specified in the
IPvX Addr Count field. These fields are used for troubleshooting
misconfigured routers. If more than one address is sent, it is
recommended that all routers be configured to send these addresses in
the same order to simplify comparisons.
For IPv4 addresses, this refers to one or more IPv4 addresses that
are backed up by the Virtual Router.
For IPv6, the first address MUST be the IPv6 link-local address
associated with the Virtual Router.
This field contains either one or more IPv4 addresses or one or more
IPv6 addresses. The address family of the addresses, IPv4 or IPv6
but not both, MUST be the same as the VRRP packet's IPvX header
address family.
Protocol State MachineParameters per Virtual Router
VRID
Virtual Router Identifier. Configurable
value in the range 1-255 (decimal). There
is no default.
Priority
Priority value to be used by this VRRP
Router in Active Router election for this
Virtual Router. The value of 255
(decimal) is reserved for the router that
owns the IPvX address associated with the
Virtual Router. The value of 0 (zero) is
reserved for the Active Router to
indicate it is relinquishing responsibility
for the Virtual Router. The range 1-254
(decimal) is available for VRRP Routers
backing up the Virtual Router. Higher
values indicate higher priorities. The
default value is 100 (decimal).
IPv4_Addresses
One or more IPv4 addresses associated
with this Virtual Router. Configured
list of addresses with no default.
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.
IPvX_Addresses
Refer to either the IPv4 or IPv6 address associated
with this Virtual Router (see IPv4_Addresses and
IPv6_Addresses above).
Advertisement_Interval
Time interval between VRRP Advertisements
(centiseconds) sent by this Virtual Router.
Default is 100 centiseconds (1 second).
Active_Adver_Interval
Advertisement interval contained in
VRRP Advertisements received from the Active
Router (in centiseconds). This value is saved by
Virtual Routers in the Backup state and
used to compute Skew_Time (as specified in )
and Active_Down_Interval. The initial value
is the same as Advertisement_Interval.
Skew_Time
Time to skew Active_Down_Interval in
centiseconds. Calculated as:
(((256 - Priority) * Active_Adver_Interval) / 256)
Active_Down_Interval
Time interval for the Backup Router to declare
the Active Router down (centiseconds).
Calculated as:
(3 * Active_Adver_Interval) + Skew_Time
Preempt_Mode
Controls whether a (starting or
restarting) higher-priority Backup Router
preempts a lower-priority Active Router.
Values are True to allow preemption and
False to prohibit preemption. Default is
True.
Note: The exception is that the router
that owns the IPvX address associated
with the Virtual Router always preempts,
independent of the setting of this flag.
Accept_Mode
Controls whether a Virtual Router in
Active state will accept packets
addressed to the address owner's IPvX
address as its own even if it is not the IPvX
address owner. The default is False.
Deployments that rely on, for example,
pinging the address owner's IPvX address
may wish to configure Accept_Mode to
True.
Note: IPv6 Neighbor Solicitations and
Neighbor Advertisements MUST NOT be
dropped when Accept_Mode is False.
Virtual_Router_MAC_Address
The MAC address used for the source MAC
address in VRRP advertisements and
advertised in ARP/ND messages as
the MAC address to use for IPvX_Addresses.
Timers
Active_Down_Timer
Timer that fires when a VRRP Advertisement has not
been received for Active_Down_Interval (Backup Routers only).
Adver_Timer
Timer that fires to trigger transmission of
a VRRP Advertisement based on the Advertisement_Interval (Active Routers only).
State Transition DiagramState Transition Diagram
+---------------+
+--------->| |<-------------+
| | Initialize | |
| +------| |----------+ |
| | +---------------+ | |
| | | |
| V V |
+---------------+ +---------------+
| |---------------------->| |
| Active | | Backup |
| |<----------------------| |
+---------------+ +---------------+
State Descriptions
In the state descriptions below, the state names are identified by
{state-name}, and the packets are identified by all-uppercase
characters.
A VRRP Router implements an instance of the state machine for each
Virtual Router in which it is participating.
Initialize
The purpose of this state is to wait for a Startup event, that is, an
implementation-defined mechanism that initiates the protocol once it
has been configured. The configuration mechanism is out of scope for
this specification.
If a Startup event is received, then:
If the Priority = 255, i.e., the router owns the IPvX
address(es) associated with the Virtual Router, then:
Send an ADVERTISEMENT
If the protected IPvX address is an IPv4 address, then:
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.
else // IPv6
For each IPv6 address associated with the Virtual
Router, send an unsolicited ND Neighbor
Advertisement with the Router Flag (R) set, the
Solicited Flag (S) clear, the Override flag (O)
set, the target address set to the IPv6 address
of the Virtual Router, and the target link-layer
address set to the Virtual Router MAC address.
endif // was protected address IPv4?
Set the Adver_Timer to Advertisement_Interval
Transition to the {Active} state
else // Router is not the address owner
Set the Active_Adver_Interval to Advertisement_Interval
Set the Active_Down_Timer to Active_Down_Interval
Transition to the {Backup} state
endif // was priority 255?
endif // Startup event was receivedBackup
The purpose of the {Backup} state is to monitor the availability and
state of the Active Router. The Solicited-Node multicast address
is referenced in the pseudocode below.
While in the {Backup} state, a VRRP Router MUST do the following:
If the protected IPvX address is an IPv4 address,
then:
It MUST NOT respond to ARP requests for the IPv4
address(es) associated with the Virtual Router.
else // protected address is IPv6
It MUST NOT respond to ND Neighbor Solicitation messages
for the IPv6 address(es) associated with the Virtual Router.
It MUST NOT send ND Router Advertisement messages
for the Virtual Router.
endif // was protected address IPv4?
It MUST discard packets with a destination link-layer
MAC address equal to the Virtual Router MAC address.
It MUST NOT accept packets addressed to the IPvX
address(es) associated with the Virtual Router.
If a Shutdown event is received, then:
Cancel the Active_Down_Timer
Transition to the {Initialize} state
endif // Shutdown event received
If the Active_Down_Timer fires, then:
Send an ADVERTISEMENT
If the protected IPvX address is an IPv4 address, then:
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.
else // IPv6
Compute and join the Solicited-Node multicast
address for the IPv6 address(es)
associated with the Virtual Router.
For each IPv6 address associated with the
Virtual Router, send an unsolicited ND Neighbor
Advertisement with the Router Flag (R) set, the
Solicited Flag (S) clear, the Override flag (O)
set, the target address set to the IPv6 address
of the Virtual Router, and the target link-layer
address set to the Virtual Router MAC address.
endif // was protected address IPv4?
Set the Adver_Timer to Advertisement_Interval
Transition to the {Active} state
endif // Active_Down_Timer fired
If an ADVERTISEMENT is received, then:
If the Priority in the ADVERTISEMENT is 0, then:
Set the Active_Down_Timer to Skew_Time
else // priority non-zero
If Preempt_Mode is False, or if the Priority in
the ADVERTISEMENT is greater than or equal to the
local Priority, then:
Set the Active_Adver_Interval to the Max Advertise
Interval contained in the ADVERTISEMENT
Recompute the Skew_Time
Recompute the Active_Down_Interval
Set the Active_Down_Timer to Active_Down_Interval
else // preempt was true and priority was less
than the local priority
Discard the ADVERTISEMENT
endif // preempt test
endif // was priority 0?
endif // was advertisement received?
endwhile // {Backup} stateActive
While in the {Active} state, the router functions as the forwarding
router for the IPvX address(es) associated with the Virtual Router.
Note that in the {Active} state, the Preempt_Mode Flag is not
considered.
While in the {Active} state, a VRRP Router MUST do the following:
If the protected IPvX address is an IPv4 address, then:
It MUST respond to ARP requests for the IPv4
address(es) associated with the Virtual Router.
else // IPv6
It MUST be a member of the Solicited-Node multicast
address for the IPv6 address(es) associated with the
Virtual Router.
It MUST respond to ND Neighbor Solicitation messages (with
the Router Flag (R) set) for the IPv6 address(es) associated
with the Virtual Router.
It MUST send ND Router Advertisements for the Virtual
Router.
If Accept_Mode is False:
It MUST NOT drop IPv6
Neighbor Solicitations and Neighbor Advertisements.
endif // IPv4?
It MUST forward packets with a destination link-layer MAC
address equal to the Virtual Router MAC address.
It MUST accept packets addressed to the IPvX address(es)
associated with the Virtual Router if it is the IPvX
address owner or if Accept_Mode is True. Otherwise, it
MUST NOT accept these packets.
If a Shutdown event is received, then:
Cancel the Adver_Timer
Send an ADVERTISEMENT with Priority = 0
Transition to the {Initialize} state
endif // shutdown received
If the Adver_Timer fires, then:
Send an ADVERTISEMENT
Reset the Adver_Timer to Advertisement_Interval
endif // advertisement timer fired
If an ADVERTISEMENT is received, then:
If the Priority in the ADVERTISEMENT is 0, then:
Send an ADVERTISEMENT
Reset the Adver_Timer to Advertisement_Interval
else // priority was non-zero
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:
Cancel Adver_Timer
Set the Active_Adver_Interval to the Max Advertise
Interval contained in the ADVERTISEMENT
Recompute the Skew_Time
Recompute the Active_Down_Interval
Set the Active_Down_Timer to Active_Down_Interval
Transition to the {Backup} state
else // new Active Router logic
Discard the ADVERTISEMENT
Send an ADVERTISEMENT immediately to assert
the {Active} state to the sending VRRP Router and
to update any learning bridges with the correct
Active VRRP Router path.
endif // new Active Router detected
endif // was priority zero?
endif // advert received
endwhile // in {Active} state
Note: VRRP packets are transmitted with the Virtual Router MAC
address as the source MAC address to ensure that learning bridges
correctly determine the LAN segment to which the Virtual Router is
attached.
Sending and Receiving VRRP PacketsReceiving VRRP Packets
The following functions must be performed when a VRRP packet is received:
If the received packet is an IPv4 packet, then:
It MUST verify that the IPv4 TTL is 255.
else // IPv6 VRRP packet received
It MUST verify that the IPv6 Hop Limit is 255.
endif
It MUST verify that the VRRP version is 3.
It MUST verify that the VRRP packet type is 1 (ADVERTISEMENT).
It MUST verify that the received packet contains the complete
VRRP packet (including fixed fields and the IPvX address).
It MUST verify the VRRP checksum.
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.
A receiver SHOULD also verify that the Max Advertise Interval
in the received VRRP packet matches the Advertisement_Interval
configured for the VRID. Instability can occur with differing intervals
(refer to ).
If this check fails, the receiver SHOULD log the event (subject to
rate-limiting) and MAY indicate via network management that a
misconfiguration was detected.
A receiver MAY also verify that "IPvX Addr Count" and the list
of IPvX address(es) match the IPvX address(es) configured for the VRID.
If this check fails, the receiver SHOULD log (subject to rate-limiting) the event
and MAY indicate via network management that a misconfiguration was detected.
Transmitting VRRP Packets
The following operations MUST be performed when transmitting a VRRP
packet:
Fill in the VRRP packet fields with the appropriate Virtual
Router configuration state
Compute the VRRP checksum
Set the source MAC address to the Virtual Router MAC address
If the protected address is an IPv4 address, then:
Set the source IPv4 address to the interface's primary IPv4
address
else // IPv6
Set the source IPv6 address to the interface's link-local
IPv6 address
endif
Set the IPvX protocol to VRRP
Send the VRRP packet to the VRRP IPvX multicast group
Note: VRRP packets are transmitted with the Virtual Router MAC
address as the source MAC address to ensure that learning bridges
correctly determine the LAN segment to which the Virtual Router is
attached.
Virtual Router MAC Address
The Virtual Router MAC address associated with a Virtual Router is an
IEEE 802 MAC address in the
following format:
IPv4 case: 00-00-5E-00-01-{VRID} (in hex, in network byte order)
The first three octets are derived from the IANA's Organizationally
Unique Identifier (OUI). The next two octets (00-01) indicate the
address block assigned to the VRRP protocol for the IPv4 protocol.
{VRID} is the Virtual Router Identifier. This mapping provides
for up to 255 IPv4 VRRP Routers on a LAN.
IPv6 case: 00-00-5E-00-02-{VRID} (in hex, in network byte order)
The first three octets are derived from the IANA's OUI. The next two
octets (00-02) indicate the address block assigned to the VRRP protocol for
the IPv6 protocol. {VRID} is the Virtual Router Identifier. This
mapping provides for up to 255 IPv6 VRRP Routers on a LAN.
IPv6 Interface Identifiers specifies that be used
as the default scheme for generating a stable address in IPv6 Stateless
Address Autoconfiguration (SLAAC) .
The Virtual Router MAC MUST NOT be used for the Net_Iface parameter used
in the Interface Identifier (IID) derivation algorithms in
and .
This VRRP specification describes how to advertise and resolve the
VRRP Router's IPv6 link-local address and other associated IPv6
addresses into the Virtual Router MAC address.
Operational IssuesIPv4ICMP Redirects
ICMP redirects can be used normally when VRRP is running among a
group of routers. This allows VRRP to be used in environments where
the topology is not symmetric.
The IPv4 source address of an ICMP redirect should be the address
that the end-host used when making its next-hop routing decision. If
a VRRP Router is acting as the Active Router for Virtual Router(s) containing
address(es) it does not own, then it must determine to which Virtual
Router the packet was sent when selecting the redirect source
address. One method to deduce the Virtual Router used is to examine
the destination MAC address in the packet that triggered the
redirect.
It may be useful to disable redirects for specific cases where VRRP
is being used to load-share traffic among a number of routers in a
symmetric topology.
Host ARP Requests
When a host sends an ARP request for one of the Virtual Router IPv4
addresses, the Active Router MUST respond to the ARP request
with an ARP response that indicates the Virtual Router MAC address for the
Virtual Router. Note that the source address of the Ethernet frame
of this ARP response is the physical MAC address of the physical
router. The Active Router MUST NOT respond with its physical
MAC address in the ARP response. This allows the host to always
use the same MAC address, regardless of the current Active Router.
When a VRRP Router restarts or boots, it SHOULD NOT send any ARP
messages using its physical MAC address for an IPv4 address for
which it is the IPv4 address owner (as defined in ),
and it should only send ARP messages that include Virtual Router MAC addresses.
This entails the following:
When configuring an interface, Active Routers
SHOULD broadcast a gratuitous ARP message containing the Virtual
Router MAC address for each IPv4 address on that interface.
At system boot, when initializing interfaces for VRRP operation,
gratuitous ARP messages MUST be delayed until both the
IPv4 address and the Virtual Router MAC address are configured.
When, for example, Secure Shell (SSH) access to a particular VRRP Router is
required, an IPv4 address known to belong to that router SHOULD be
used.
Proxy ARP
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. Doing otherwise could cause hosts to learn the real MAC
address of the VRRP Router.
IPv6ICMPv6 Redirects
ICMPv6 redirects can be used normally when VRRP is running among a
group of routers . This allows VRRP to be used in
environments where the topology is not symmetric, e.g., the VRRP
Routers do not connect to the same destinations.
The IPv6 source address of an ICMPv6 redirect SHOULD be the address
that the end-host used when making its next-hop routing decision. If
a VRRP Router is acting as the Active Router for Virtual Router(s) containing
address(es) it does not own, then it has to determine to which Virtual
Router the packet was sent when selecting the redirect source
address. A method to deduce the Virtual Router used is to examine
the destination MAC address in the packet that triggered the
redirect.
ND Neighbor Solicitation
When a host sends an ND Neighbor Solicitation message for a Virtual
Router IPv6 address, the Active Router MUST respond to the ND
Neighbor Solicitation message with the Virtual Router MAC address for the
Virtual Router. The Active Router MUST NOT respond with its
physical MAC address. This allows the host to always use the same
MAC address, regardless of the current Active Router.
When an Active Router sends an ND Neighbor Solicitation
message for a host's IPv6 address, the Active Router MUST
include the Virtual Router MAC address for the Virtual Router if it sends a
source link-layer address option in the Neighbor Solicitation
message. It MUST NOT use its physical MAC address in the source
link-layer address option.
When a VRRP Router restarts or boots, it SHOULD NOT send any ND
messages with its physical MAC address for the IPv6 address it owns
and it should only send ND messages that include Virtual Router MAC addresses.
This entails the following:
When configuring an interface, Active Routers
SHOULD send an unsolicited ND Neighbor Advertisement message
containing the Virtual Router MAC address for the IPv6 address on
that interface.
At system boot, when initializing interfaces for VRRP operation,
all ND Router Advertisements, ND Neighbor Advertisements, and ND Neighbor Solicitation
messages MUST be delayed until both the IPv6 address and the
Virtual Router MAC address are configured.
Note that on a restarting Active Router where the VRRP protected
address is an interface address, i.e., the address owner, Duplicate
Address Detection may fail, as the Backup Router MAY answer
that it owns the address. One solution is to not run Duplicate
Address Detection in this case.
Router Advertisements
When a Backup VRRP Router has become the Active Router for a Virtual Router, it
is responsible for sending Router Advertisements for the Virtual
Router, as specified in . The Backup Routers MUST be
configured to send the same Router Advertisement options as the
address owner.
Router Advertisement options that advertise special services, e.g.,
Home Agent Information Option, that are present in the address owner
SHOULD NOT be sent by the address owner unless the Backup Routers are
prepared to assume these services in full and have a complete and
synchronized database for this service.
Unsolicited Neighbor Advertisements
A VRRP Router acting as either an IPv6 Active Router or Backup Router SHOULD
accept Unsolicited Neighbor Advertisements and update the corresponding
neighbor cache . Since these are sent to the
IPv6 all-nodes multicast address (ff02::1) or the
IPv6 all-routers multicast address (ff02::2), they will be received. Unsolicited
Neighbor Advertisements are sent both in the case where the link-level addresses
change and for gratuitous neighbor discovery by first-hop
routers . Additional configuration may be required in order
for Unsolicited Neighbor Advertisements to update the corresponding neighbor cache.
IPvXPotential Forwarding Loop
If it is not the address owner, a VRRP Router SHOULD NOT forward
packets addressed to the IPvX address for which it becomes the Active Router.
Forwarding these packets would result in unnecessary traffic. Also,
in the case of LANs that receive packets they transmit, this can result
in a forwarding loop that is only terminated when the IPvX TTL expires.
One mechanism for VRRP Routers to avoid these forwarding loops is to add/delete
a host Drop Route for each non-owned IPvX address when transitioning
to/from the Active state.
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). If no VRRP Router
has this priority, and preemption is disabled, then no preemption will occur.
In order to avoid two or more Backup Routers simultaneously becoming Active Routers after
the previous Active Router fails or is shut down, all Virtual Routers SHOULD be configured
with different priorities and with sufficient differences in the priorities so that lower
priority Backup Routers do not transition to the Active state before receiving an advertisement
from the highest priority Backup Router when it transitions to the Active Router. If
multiple VRRP Routers advertising the same priority are detected, this condition MAY
be logged as a warning (subject to rate-limiting).
Since the Skew_Time is reduced as the priority is increased, faster
convergence can be obtained by using a higher priority for the preferred
Backup Router. However, with multiple Backup Routers, the priorities should have
sufficient differences, as previously recommended.
VRRPv3 and VRRPv2 InteroperationAssumptions
VRRPv2 and VRRPv3 interoperation is optional.
Mixing VRRPv2 and VRRPv3 should only be done when transitioning
from VRRPv2 to VRRPv3. Mixing the two versions should not be
considered a permanent solution.
VRRPv3 Support of VRRPv2 Interoperation
As mentioned above, this support is intended for upgrade scenarios
and is NOT RECOMMENDED for permanent deployments.
An implementation MAY implement a configuration flag that tells it to
listen for and send both VRRPv2 and VRRPv3 advertisements.
When a Virtual Router is configured this way and is the Active Router, it
MUST send both types at the configured rate, even if it is sub-second.
When a Virtual Router is configured this way and is the Backup Router, it
MUST time out based on the rate advertised by the Active Router. In the
case of a VRRPv2 Active Router, this means it MUST translate the timeout
value it receives (in seconds) into centiseconds. Also, a Backup
Router SHOULD ignore VRRPv2 advertisements from the current Active Router
if it is also receiving VRRPv3 packets from it. It MAY report when a VRRPv3
Active Router is not sending VRRPv2 packets, as this suggests they don't
agree on whether they're supporting VRRPv2 interoperation.
Interoperation ConsiderationsSlow, High-Priority Active Routers
See also ,
"Maximum Advertisement Interval (Max Advertise Interval)".
The VRRPv2 Active Router interacting with a sub-second VRRPv3 Backup
Router is the most important example of this.
A VRRPv2 implementation SHOULD NOT be given a higher priority than a
VRRPv2 or VRRPv3 implementation with which it is interoperating if the
VRRPv2 or VRRPv3 router's advertisement rate is sub-second.
Overwhelming VRRPv2 Backups
It seems possible that a VRRPv3 Active Router sending at centisecond
rates could potentially overwhelm a VRRPv2 Backup Router with
potentially non-deterministic results.
In this upgrade case, a deployment should initially run the VRRPv3
Active Routers with lower frequencies, e.g., 100 centiseconds, until
the VRRPv2 routers are upgraded. Then, once the deployment has
verified that VRRPv3 is working properly, the VRRPv2 support
may be disabled and the desired sub-second rates may be configured.
Security Considerations
VRRP for IPvX does not currently include any type of authentication.
Earlier versions of the VRRP specification included
several types of authentication, ranging from no authentication to strong
authentication.
Operational experience and further analysis determined that these did
not provide sufficient security to overcome the vulnerability of
misconfigured secrets, causing multiple Active Routers to be elected.
Due to the nature of the VRRP protocol, even if VRRP messages are
cryptographically protected, it does not prevent hostile nodes from
behaving as if they are an Active Router, creating multiple
Active Routers. Authentication of VRRP messages could have prevented
a hostile node from causing all properly functioning routers from going
into the Backup state. However, having multiple Active Routers can cause
as much disruption as no routers, which authentication cannot prevent.
Also, even if a hostile node could not disrupt VRRP, it can disrupt ARP/ND
and create the same effect as having all routers go into the Backup state.
Some L2 switches provide the capability to filter out, for example,
ARP and/or ND messages from end-hosts on a switch-port basis. This
mechanism could also filter VRRP messages from switch ports
associated with end-hosts and can be considered for deployments with
untrusted hosts.
It should be noted that these attacks are not worse and are a subset
of the attacks that any node attached to a LAN can do independently
of VRRP. The kind of attacks a malicious node on a LAN can perform
include:
promiscuously receiving packets for any router's MAC address,
sending packets with the router's MAC address as the source MAC
address in the L2 header to tell the L2 switches to send packets
addressed to the router to the malicious node instead of the router,
sending redirects to tell hosts to send their traffic
somewhere else,
sending unsolicited ND replies,
answering ND requests, etc.
All of these can be done independently of implementing VRRP.
VRRP does not add to these vulnerabilities, and most of these
vulnerabilities are addressed independently, e.g., SEcure Neighbor Discovery (SEND)
.
VRRP includes a mechanism
(setting IPv4 TTL or IPv6 Hop Limit to 255 and checking the value on receipt)
that protects against VRRP packets being injected from another remote
network .
This limits most vulnerabilities to attacks on the local
network.
VRRP does not provide any confidentiality. 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.
In the context of IPv6 operation, if SEND
is deployed, VRRP is compatible with the "trust anchor" and "trust
anchor or CGA" modes of SEND . The SEND
configuration needs to give the Active and Backup Routers the same prefix
delegation in the certificates so that Active and Backup Routers advertise
the same set of subnet prefixes. However, the Active and Backup Routers
should have their own key pairs to avoid private key sharing.
Also in the context of IPv6 operation, it is RECOMMENDED that the
link-level security guidelines in
be followed.
IANA Considerations
IANA has updated all IANA registry references to
to references to RFC 9568, i.e., this document. The individual IANA
references are listed below.
The value 112 is assigned to VRRP in the "Assigned Internet Protocol Numbers" registry.
In the "Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry of the
"IPv4 Multicast Address Space Registry" , IANA has assigned
the IPv4 multicast address 224.0.0.18 for VRRP.
In the "Link-Local Scope Multicast Addresses" registry of the "IPv6 Multicast Address
Space Registry" , IANA has assigned the IPv6 link-local
scope multicast address ff02:0:0:0:0:0:0:12 for VRRP for IPv6.
In the "IANA MAC ADDRESS BLOCK" registry ,
IANA has assigned blocks of Ethernet unicast addresses as
follows (in hexadecimal):
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Allocation Guidelines for IPv6 Multicast AddressesIP Version 6 Addressing ArchitectureThis specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) SpecificationThis document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]Neighbor Discovery for IP version 6 (IPv6)This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]The Generalized TTL Security Mechanism (GTSM)The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]IANA Guidelines for IPv4 Multicast Address AssignmentsThis document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780. This memo documents an Internet Best Current Practice.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Internet Protocol, Version 6 (IPv6) SpecificationThis document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 ParametersSome IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA Organizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042.Informative ReferencesDevelopment of Router Clusters to Provide Fast Failover in IP NetworksDigital Technical Journal, Volume 9, Number 3Guidance for NIST Staff on Using Inclusive Language in Documentary Standards,National Institute of Standards and Technology (NIST)Computing the Internet checksumThis RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.ICMP Router Discovery MessagesThis document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. [STANDARDS-TRACK]Dynamic Host Configuration ProtocolThe Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]Cisco Hot Standby Router Protocol (HSRP)The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.OSPF Version 2This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]Virtual Router Redundancy ProtocolThis memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. [STANDARDS-TRACK]RIP Version 2This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]Virtual Router Redundancy Protocol (VRRP)This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK]SEcure Neighbor Discovery (SEND)IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]IPv6 Host-to-Router Load SharingThe original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. [STANDARDS-TRACK]IPv6 Stateless Address AutoconfigurationThis document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).Recommendation on Stable IPv6 Interface IdentifiersThis document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.Operational Security Considerations for IPv6 NetworksKnowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices.This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks.Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop RoutersNeighbor Discovery (RFC 4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document updates RFC 4861 to allow routers to proactively create a Neighbor Cache entry when a new IPv6 address is assigned to a node. It also updates RFC 4861 and recommends that nodes send unsolicited Neighbor Advertisements upon assigning a new IPv6 address. These changes will minimize the delay and packet loss when a node initiates connections to an off-link destination from a new IPv6 address.Virtual Router Redundancy Protocol for IPv6NokiaCisco SystemsWork in ProgressAcknowledgments
The IPv6 text in this specification is based on . The
authors of are , , , ,
, , , , and .
The authors of would also like to thank ,
, , , , , , , , and for
their helpful suggestions.
The IPv4 text in this specification is based on . The
authors of that specification would like to thank , , , , , , , , , , ,
, , , , , , , and for their comments and suggestions.
Thanks to for his work merging/editing
and into the document that eventually became
.
Thanks to , , , ,
, , , , , ,
, and for comments on the current document (RFC 9568).
Thanks to , , and for discussions related to the removal
of legacy technology appendices. Thanks to and for
comments and suggestions for improving the IANA section. Thanks to
for recommending "Maximum Advertisement Interval" validation. Thanks to and
for discussions and updates related to IPv6 SLAAC.
Special thanks to for a detailed review and extensive comments on the
current document (RFC 9568).
Authors' AddressesLabN Consulting, L.L.C.301 Midenhall WayCaryNC27513United States of Americaacee.ietf@gmail.comCisco SystemsSarjapur Outer Ring RoadBangaloreKarnataka560103Indiaaddogra@cisco.com