rfc9568.original.xml   rfc9568.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc> <!ENTITY zwsp "&#8203;">
<!-- used by XSLT processors --> <!ENTITY nbhy "&#8209;">
<!-- For a complete list and description of processing instructions (PIs), <!ENTITY wj "&#8288;">
please see http://xml.resource.org/authoring/README.html. --> ]>
<rfc <rfc
xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xi="http://www.w3.org/2001/XInclude"
category="std" category="std"
docName="draft-ietf-rtgwg-vrrp-rfc5798bis-18" docName="draft-ietf-rtgwg-vrrp-rfc5798bis-18"
ipr="trust200902" ipr="trust200902"
number="9568"
obsoletes="5798" obsoletes="5798"
updates="" updates=""
submissionType="IETF" submissionType="IETF"
xml:lang="en" xml:lang="en"
tocInclude="true" tocInclude="true"
tocDepth="4" tocDepth="4"
symRefs="true" symRefs="true"
sortRefs="true" sortRefs="true"
consensus="true" consensus="true"
version="3"> version="3">
<!-- xml2rfc v2v3 conversion 2.38.1 --> <!-- xml2rfc v2v3 conversion 2.38.1 -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200
902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="VRRP Version 3">Virtual Router Redundancy Protocol (VRRP) Ver sion 3 for IPv4 and IPv6</title> <title abbrev="VRRP Version 3">Virtual Router Redundancy Protocol (VRRP) Ver sion 3 for IPv4 and IPv6</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-vrrp-rfc5798bis.xm <seriesInfo name="RFC" value="9568"/>
l"/>
<!-- Another author who claims to be an editor -->
<author initials="A" surname="Lindem" fullname="Acee Lindem"> <author initials="A" surname="Lindem" fullname="Acee Lindem">
<organization>LabN Consulting, L.L.C.</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<postal> <postal>
<street>301 Midenhall Way</street> <street>301 Midenhall Way</street>
<city>Cary</city> <city>Cary</city>
<region>NC</region> <region>NC</region>
<code>27513</code> <code>27513</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>acee.ietf@gmail.com</email> <email>acee.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="A" surname="Dogra" fullname="Aditya Dogra"> <author initials="A" surname="Dogra" fullname="Aditya Dogra">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>Sarjapur Outer Ring Road</street> <street>Sarjapur Outer Ring Road</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560103</code> <code>560103</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>addogra@cisco.com</email> <email>addogra@cisco.com</email>
</address> </address>
</author> </author>
<date/> <date month="April" year="2024"/>
<area>General</area> <area>Routing Area</area>
<keyword>RFC</keyword>
<keyword>VRRP</keyword> <keyword>VRRP</keyword>
<abstract> <abstract>
<t> <t>
This document defines version 3 of the Virtual Router Redundancy Protoco l (VRRP) This document defines version 3 of the Virtual Router Redundancy Protoco l (VRRP)
for IPv4 and IPv6. It obsoletes RFC 5798 which previously specified VRRP for IPv4 and IPv6. It obsoletes RFC 5798, which previously specified VRR
(version 3). P (version 3).
RFC 5798 obsoleted RFC 3768 which specified VRRP (version 2) for IPv4. RFC 5798 obsoleted RFC 3768, which specified VRRP (version 2) for IPv4.
VRRP specifies an election protocol that dynamically assigns responsibil ity for a VRRP specifies an election protocol that dynamically assigns responsibil ity for a
Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router 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 controlling the IPv4 or IPv6 address(es) associated with a Virtual
Router is called the Active Router, and it forwards packets routed to th ese Router is called the Active Router, and it forwards packets routed to th ese
IPv4 or IPv6 addresses. Active Routers are configured with IPv4 or IPv6 addresses. Active Routers are configured with
virtual IPv4 or IPv6 addresses, and Backup Routers infer the virtual IPv4 or IPv6 addresses, and Backup Routers infer the
address family of the virtual addresses being advertised based on the address family of the virtual addresses being advertised based on the
IP protocol version. Within a VRRP Router, the Virtual Routers in IP protocol version. Within a VRRP Router, the Virtual Routers in
each of the IPv4 and IPv6 address families are independent of one anothe r each of the IPv4 and IPv6 address families are independent of one anothe r
and always treated as separate Virtual Router instances. and always treated as separate Virtual Router instances.
skipping to change at line 102 skipping to change at line 91
switchover to Backup Routers than can be obtained with standard IPv6 switchover to Backup Routers than can be obtained with standard IPv6
Neighbor Discovery mechanisms. Neighbor Discovery mechanisms.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1"> <section anchor="sect-1">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
This document defines version 3 of the Virtual Router Redundancy Protoco l (VRRP) This document defines version 3 of the Virtual Router Redundancy Protoco l (VRRP)
for IPv4 and IPv6. It obsoletes RFC 5798 <xref target="RFC5798"/> which for IPv4 and IPv6. It obsoletes <xref target="RFC5798"/>, which previous
previously ly
specified VRRP (version 3). RFC 5798 obsoleted RFC 3768 <xref target="RF specified VRRP (version 3). <xref target="RFC5798"/> obsoleted <xref tar
C3768"/> get="RFC3768"/>,
which specified VRRP (version 2) for IPv4. which specified VRRP (version 2) for IPv4.
VRRP specifies an election protocol that dynamically VRRP specifies an election protocol that dynamically
assigns responsibility for a Virtual Router assigns responsibility for a Virtual Router
(refer to <xref target="sect-1.7"/>) to one of the VRRP (refer to <xref target="sect-1.7"/>) to one of the VRRP
routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6
address(es) associated with a Virtual Router is called the Active Router , address(es) associated with a Virtual Router is called the Active Router ,
and it forwards packets routed to these IPv4 or IPv6 addresses (except f or and it forwards packets routed to these IPv4 or IPv6 addresses (except f or
packets addressed to these addresses as decribed in <xref target="sect-8 .3.1"/>). packets addressed to these addresses as described in <xref target="sect- 8.3.1"/>).
VRRP Active Routers are configured with virtual IPv4 or IPv6 addresses, VRRP Active Routers are configured with virtual IPv4 or IPv6 addresses,
and Backup Routers infer the address family of the virtual and Backup Routers infer the address family of the virtual
addresses being advertised based on the IP protocol version. Within a addresses being advertised based on the IP protocol version. Within a
VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address
families are independent of one another families are independent of one another
and always treated as separate Virtual Router instances. The and always treated as separate Virtual Router instances. The
election process provides dynamic failover in the forwarding election process provides dynamic failover in the forwarding
responsibility should the Active Router become unavailable. responsibility should the Active Router become unavailable.
</t> </t>
<t> <t>
VRRP provides a function similar to the proprietary protocols "Hot Stand VRRP provides a function similar to the proprietary protocols Hot Standb
by Router Protocol (HSRP)" y Router Protocol (HSRP)
<xref target="RFC2281"/> and "IP Standby Protocol" <xref target="IPSTB"/ <xref target="RFC2281"/> and IP Standby Protocol <xref target="IPSTB"/>.
>.
</t> </t>
<section anchor="sect-1.1"> <section anchor="sect-1.1">
<name>RFC 5798 Differences</name> <name>Differences from RFC 5798</name>
<t> <t>
The following changes have been made from RFC 5798: The following changes have been made from <xref target="RFC5798"/>:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
The VRRP terminology has been updated to conform to inclusive languag e The VRRP terminology has been updated to conform to inclusive languag e
guidelines for IETF technologies. guidelines for IETF technologies.
The IETF has designated National Institute of Standards and Technolo The IETF has designated the National Institute of Standards and Tech
gy (NIST) nology (NIST)
"Guidance for NIST Staff on Using Inclusive Language in Documentary document "Guidance for NIST Staff on Using Inclusive Language in Doc
Standards" umentary Standards"
<xref target="NISTIR8366"/> for its inclusive language guidelines. <xref target="NISTIR8366"/> for its inclusive language guidelines.
</li> </li>
<li> <li>
The term for the VRRP Router assuming forwarding responsibility has been changed The term for the VRRP Router assuming forwarding responsibility has been changed
to "Active Router" to be consistent with IETF inclusive terminology. Additionally, to "Active Router" to be consistent with IETF inclusive terminology. Additionally,
inconsistencies in RFC 5798 terminology for both "Active Router" and "Backup Router" inconsistencies in the terminology of <xref target="RFC5798"/> for b oth "Active Router" and "Backup Router"
were corrected. Additionally, the undesirable term for attracting an d dropping were corrected. Additionally, the undesirable term for attracting an d dropping
unreachable packets has been changed. unreachable packets has been changed.
</li> </li>
<li> <li>
Errata pertaining to the state machines in <xref target="state-machi ne"/> were Errata pertaining to the state machines in <xref target="state-machi ne"/> were
corrected. corrected.
</li> </li>
<li> <li>
The checksum calculation in <xref target="sect-5.2.8"/> has been cla rified to specify The checksum calculation in <xref target="sect-5.2.8"/> has been cla rified to specify
precisely what is included and that it does not include the pseudo-h eader for IPv4. precisely what is included and that it does not include the pseudo-h eader for IPv4.
</li> </li>
<li> <li>
When a VRRP advertisement is received from a lower priority VRRP rou When a VRRP advertisement is received from a lower priority VRRP Rou
ter, the Active ter, the Active
VRRP router will immediately send a VRRP advertisement to assure lea VRRP Router will immediately send a VRRP advertisement to assure lea
rning bridges rning bridges
will bridge the packets to the correct Ethernet segment will bridge the packets to the correct Ethernet segment
(refer to <xref target="sect-6.4.3"/>). (refer to <xref target="sect-6.4.3"/>).
</li> </li>
<li> <li>
Appendices describing operation over legacy technologies (FDDI, Toke n Appendices describing operation over legacy technologies (Fiber Dist ributed Data Interface (FDDI), Token
Ring, and ATM LAN Emulation) were removed. Ring, and ATM LAN Emulation) were removed.
</li> </li>
<li> <li>
A recommendation was added indicating that IPv6 Unsolicited Neighbor Advertisements A recommendation was added indicating that IPv6 Unsolicited Neighbor Advertisements
SHOULD be accepted by the Active and Backup Routers <xref target="se ct-8.2.4"/>. <bcp14>SHOULD</bcp14> be accepted by the Active and Backup Routers ( <xref target="sect-8.2.4"/>).
</li> </li>
<li> <li>
Checking that the Maximum Advertisement Intervals match is recommend Checking that the Maximum Advertisement Intervals match is recommend
ed although this will ed, although this will
not result in the VRRP packet being dropped <xref target="sect-7.1"/ not result in the VRRP packet being dropped (<xref target="sect-7.1"
>. />).
</li> </li>
<li> <li>
Miscellaneous editorial changes were made for readability. Miscellaneous editorial changes were made for readability.
</li> </li>
<li> <li>
The IANA Considerations section was augmented to include all the IPv 4/IPv6 The IANA Considerations section was augmented to include all the IPv 4/IPv6
multicast address allocations and Ethernet MAC address allocations. multicast address allocations and Ethernet Media Access Control (MAC ) address allocations.
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="sect-1.2"> <section anchor="sect-1.2">
<name>A Note on Terminology</name> <name>A Note on Terminology</name>
<t> <t>
This document discusses both IPv4 and IPv6 operations, and with This document discusses both IPv4 and IPv6 operations, and with
respect to the VRRP protocol, many of the descriptions and procedures 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 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, refer to "IP" to mean either "IPv4 or IPv6". However, historically,
skipping to change at line 199 skipping to change at line 188
mean either "IPv4" or "IPv6". In this text, where the IP version 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 matters, the appropriate term is used, and the use of the term "IP" is
avoided. avoided.
</t> </t>
</section> </section>
<section anchor="sect-1.3"> <section anchor="sect-1.3">
<name>IPv4</name> <name>IPv4</name>
<t> <t>
There are a number of methods that an IPv4 end-host can use to There are a number of methods that an IPv4 end-host can use to
determine its first-hop router for a particular IPv4 destination. determine its first-hop router for a particular IPv4 destination.
These include running (or snooping) a dynamic routing protocol such These include running (or snooping) a dynamic routing protocol such
as Routing Information Protocol (RIP) <xref target="RFC2453"/> or OSPF version 2 as Routing Information Protocol (RIP) <xref target="RFC2453"/> or OSPF version 2
<xref target="RFC2328"/>, running an ICMP router discovery client <xref target="RFC2328"/>, running an ICMP router discovery client
<xref target="RFC1256"/>, DHCPv4 <xref target="RFC2131"/>, or using a <xref target="RFC1256"/>, running DHCPv4 <xref target="RFC2131"/>, or using a
statically configured default route. statically configured default route.
</t> </t>
<t> <t>
Running a dynamic routing protocol on every end-host may Running a dynamic routing protocol on every end-host may
not be feasible for a number of reasons, including administrative not be feasible for a number of reasons, including administrative
overhead, processing overhead, security issues, or the lack of an overhead, processing overhead, security issues, or the lack of an
implementation for a particular platform. Neighbor or router discover y implementation for a particular platform. Neighbor or router discover y
protocols may require active participation by all hosts on a network, protocols may require active participation by all hosts on a network,
requiring large timer values to reduce protocol overhead associated requiring large timer values to reduce protocol overhead associated
with the protocol packet processing for each host. This can result in with the protocol packet processing for each host. This can result in
a significant delay in the detection of an unreachable router and, a significant delay in the detection of an unreachable router, and
such a delay may introduce unacceptably long periods of unreachability for the such a delay may introduce unacceptably long periods of unreachability for the
default route. default route.
</t> </t>
<t> <t>
The use of a manually configured default route (either via a static rou te The use of a manually configured default route (either via a static rou te
or DHCPv4) is quite popular since it minimizes configuration and or DHCPv4) is quite popular since it minimizes configuration and
processing overhead on the end-host and processing overhead on the end-host and
is supported by virtually every IPv4 implementation. is supported by virtually every IPv4 implementation.
However, this creates a single point of failure. Loss of the default However, this creates a single point of failure. Loss of the default
router results in a catastrophic event, isolating all end-hosts that router results in a catastrophic event, isolating all end-hosts that
skipping to change at line 236 skipping to change at line 226
<t> <t>
The Virtual Router Redundancy Protocol (VRRP) is designed to The Virtual Router Redundancy Protocol (VRRP) is designed to
eliminate the single point of failure inherent in a network utilizing eliminate the single point of failure inherent in a network utilizing
default routing. VRRP specifies an election protocol that default routing. VRRP specifies an election protocol that
dynamically assigns responsibility for a Virtual Router to one of the dynamically assigns responsibility for a Virtual Router to one of the
VRRP Routers on a LAN. The VRRP Router controlling the IPv4 VRRP Routers on a LAN. The VRRP Router controlling the IPv4
address(es) associated with a Virtual Router is called the Active Rout er and address(es) associated with a Virtual Router is called the Active Rout er and
forwards packets sent to these IPv4 addresses. The election process forwards packets sent to these IPv4 addresses. The election process
provides dynamic failover of the forwarding responsibility should the provides dynamic failover of the forwarding responsibility should the
Active Router become unavailable. Any of the Virtual Router's IPv4 Active Router become unavailable. Any of the Virtual Router's IPv4
addresses on a LAN can then be used as the default first hop 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 router by end-hosts. The advantage gained from using VRRP is a
higher availability default path without requiring configuration of higher availability default path without requiring configuration of
dynamic routing or a router discovery protocol on every end-host. dynamic routing or a router discovery protocol on every end-host.
</t> </t>
</section> </section>
<section anchor="sect-1.4"> <section anchor="sect-1.4">
<name>IPv6</name> <name>IPv6</name>
<t> <t>
IPv6 hosts on a LAN will usually learn about one or more default IPv6 hosts on a LAN will usually learn about one or more default
routers by receiving Router Advertisements sent using the IPv6 routers by receiving Router Advertisements sent using the IPv6
skipping to change at line 268 skipping to change at line 258
by sending unicast ND Neighbor Solicitation messages to the neighbor by sending unicast ND Neighbor Solicitation messages to the neighbor
node. To reduce the overhead of sending Neighbor Solicitations, they node. To reduce the overhead of sending Neighbor Solicitations, they
are only sent to neighbors to which the node is actively sending are only sent to neighbors to which the node is actively sending
traffic and only after there has been no positive indication that the 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 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 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 unreachable before it will switch to another default router. This
delay would be very noticeable to users and cause some transport delay would be very noticeable to users and cause some transport
protocol implementations to time out. protocol implementations to time out.
</t> </t>
<t> <t>
While the ND unreachability detection could be made quicker by While the Neighbor Unreachability Detection could be made quicker by
configuring the timer intervals to be more aggressive (note that the c urrent configuring the timer intervals to be more aggressive (note that the c urrent
lower limit for this is 5 seconds), this would have the downside of lower limit for this is 5 seconds), this would have the downside of
significantly increasing the overhead of ND traffic, especially when significantly increasing the overhead of ND traffic, especially when
there are many hosts all trying to determine the reachability of one there are many hosts all trying to determine the reachability of one
or more routers. or more routers.
</t> </t>
<t> <t>
The Virtual Router Redundancy Protocol for IPv6 provides a much The Virtual Router Redundancy Protocol for IPv6 provides a much
faster switchover to an alternate default router than can be obtained faster switchover to an alternate default router than can be obtained
using standard ND procedures. Using VRRP, a Backup Router can take using standard ND procedures. Using VRRP, a Backup Router can take
over for a failed default router in around three seconds (using VRRP over for a failed default router in around three seconds (using VRRP
default parameters). This is done without any interaction with the default parameters). This is done without any interaction with the
hosts and a minimum amount of VRRP traffic. hosts and a minimum amount of VRRP traffic.
</t> </t>
</section> </section>
<section anchor="sect-1.5"> <section anchor="sect-1.5">
<name>Requirements Language</name> <name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP 14 <xref target="RFC2119"/> <xref RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
target="RFC8174"/> when, and only when, they appear in all capitals, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
as shown here. be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section anchor="sect-1.6"> <section anchor="sect-1.6">
<name>Scope</name> <name>Scope</name>
<t> <t>
The remainder of this document describes the features, design goals, The remainder of this document describes the features, design goals,
and theory of operation of VRRP. The message formats, protocol and theory of operation of VRRP. The message formats, protocol
processing rules, and state machine that guarantee convergence to a processing rules, and state machine that guarantee convergence to a
single Active Router are presented. Finally, operational single Active Router are presented. Finally, operational
issues related to MAC address mapping, handling of ARP messages, issues related to MAC address mapping, handling of ARP messages,
skipping to change at line 379 skipping to change at line 369
of the interface over which the packet is of the interface over which the packet is
transmitted is used. transmitted is used.
</t> </t>
</dd> </dd>
<dt>Forwarding Responsibility</dt> <dt>Forwarding Responsibility</dt>
<dd> <dd>
<t> <t>
The responsibility for forwarding packets sent to The responsibility for forwarding packets sent to
the IPvX address(es) associated with the the IPvX address(es) associated with the
Virtual Router. This includes receiving packets Virtual Router. This includes receiving packets
sent to the Virtual Router MAC Address, forwarding these sent to the Virtual Router MAC address, forwarding these
packets based on the local RIB (Routing Information Base)/FIB packets based on the local Routing Information Base (RIB) /
(Forwarding Information Base), answering Forwarding Information Base (FIB), answering
ARP requests for the IPv4 address(es), and answering ND ARP requests for the IPv4 address(es), and answering ND
requests for the IPv6 address(es). requests for the IPv6 address(es).
</t> </t>
</dd> </dd>
<dt>Active Router</dt> <dt>Active Router</dt>
<dd> <dd>
<t> <t>
The VRRP Router that is assuming the The VRRP Router that is assuming the
responsibility of forwarding packets sent to responsibility of forwarding packets sent to
the IPvX address(es) associated with the the IPvX address(es) associated with the
skipping to change at line 410 skipping to change at line 400
<dd> <dd>
<t> <t>
The set of VRRP Routers available to assume The set of VRRP Routers available to assume
forwarding responsibility for a Virtual forwarding responsibility for a Virtual
Router should the current Active Router fail. Router should the current Active Router fail.
</t> </t>
</dd> </dd>
<dt>Drop Route</dt> <dt>Drop Route</dt>
<dd> <dd>
<t> <t>
A route installed in the RIB (Routing Information Base) that A route installed in the Routing Information Base (RIB) that
will result in traffic with a destination address that matches will result in traffic with a destination address that matches
the route to be dropped. the route to be dropped.
</t> </t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="sect-2"> <section anchor="sect-2">
<name>Required Features</name> <name>Required Features</name>
<t> <t>
This section describes the set of features that were considered This section describes the set of features that were considered
mandatory and that guided the design of VRRP. mandatory and that guided the design of VRRP.
</t> </t>
<section anchor="sect-2.1"> <section anchor="sect-2.1">
<name>IPvX Address Backup</name> <name>IPvX Address Backup</name>
<t> <t>
Backup of an IPvX address or addresses is the primary function of Backup of an IPvX address or addresses is the primary function of
VRRP. When providing election of an Active Router and the VRRP. When providing election of an Active Router and the
additional functionality described below; the protocol should additional functionality described below, the protocol should
strive to:</t> strive to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Minimize the duration of unreachability.</li> <li>minimize the duration of unreachability,</li>
<li>Minimize the steady-state bandwidth overhead and processing <li>minimize the steady-state bandwidth overhead and processing
complexity.</li> complexity,</li>
<li>Function over a wide variety of multiaccess LAN technologies <li>function over a wide variety of multiaccess LAN technologies
capable of supporting IPvX traffic.</li> capable of supporting IPvX traffic,</li>
<li>Allow multiple Virtual Routers on a network for load-balancing.</li <li>allow multiple Virtual Routers on a network for load-balancing, and
> </li>
<li>Support multiple logical IPvX subnets on a single LAN segment.</li> <li>support multiple logical IPvX subnets on a single LAN segment.</li>
</ul> </ul>
</section> </section>
<section anchor="sect-2.2"> <section anchor="sect-2.2">
<name>Preferred Path Indication</name> <name>Preferred Path Indication</name>
<t> <t>
A simple model of Active Router election among a set of redundant route rs is A simple model of Active Router election among a set of redundant route rs is
to treat each router with equal preference and claim victory after to treat each router with equal preference and claim victory after
converging to any router as Active Router. However, there are likely to be converging to any router as the Active Router. However, there are lik ely to be
many environments where there is a distinct preference (or range of many environments where there is a distinct preference (or range of
preferences) among the set of redundant routers. For example, this preferences) among the set of redundant routers. For example, this
preference may be based upon access link cost or speed, router preference may be based upon access link cost or speed, router
performance or reliability, or other policy considerations. The performance or reliability, or other policy considerations. The
protocol should allow the expression of this relative path preference protocol should allow the expression of this relative path preference
in an intuitive manner and guarantee Active Router convergence to the most in an intuitive manner and guarantee Active Router convergence to the most
preferred Virtual Router currently available. preferred Virtual Router currently available.
</t> </t>
</section> </section>
<section anchor="sect-2.3"> <section anchor="sect-2.3">
<name>Minimization of Unnecessary Service Disruptions</name> <name>Minimization of Unnecessary Service Disruptions</name>
<t> <t>
Once Active Router election has been performed, any unnecessary transit ion Once Active Router election has been performed, any unnecessary transit ion
between Active and Backup Routers can result in a disruption in between Active and Backup Routers can result in a disruption of
service. The protocol should ensure that, after Active Router electio n, no service. The protocol should ensure that, after Active Router electio n, no
state transition is triggered by any Backup Router of equal or lower state transition is triggered by any Backup Router of equal or lower
preference as long as the Active Router continues to function properly . preference as long as the Active Router continues to function properly .
</t> </t>
<t> <t>
Some environments may find it beneficial to avoid the state Some environments may find it beneficial to avoid the state
transition triggered when a router that is preferred over the current transition triggered when a router that is preferred over the current
Active Router becomes available. It may be useful to support an overr ide of Active Router becomes available. It may be useful to support an overr ide of
the immediate restoration to the preferred path. the immediate restoration to the preferred path.
</t> </t>
skipping to change at line 502 skipping to change at line 492
Trigger a message immediately after transitioning to the Trigger a message immediately after transitioning to the
Active Router to update MAC learning. Active Router to update MAC learning.
</li> </li>
<li> <li>
Trigger periodic messages from the Active Router to Trigger periodic messages from the Active Router to
maintain the MAC address cache. maintain the MAC address cache.
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="sect-2.5"> <section anchor="sect-2.5">
<name>Sub-Second Operation for IPv4 and IPv6</name> <name>Sub-second Operation for IPv4 and IPv6</name>
<t> <t>
Sub-second detection of Active Router failure is needed in both Sub-second detection of Active Router failure is needed in both
IPv4 and IPv6 environments. Earlier work proposed that sub-second IPv4 and IPv6 environments. Earlier work proposed that sub-second
operation was for IPv6 and this specification leverages that earlier operation was for IPv6, and this specification leverages that earlier
approach for both IPv4 and IPv6. approach for both IPv4 and IPv6.
</t> </t>
<t> <t>
One possible problematic scenario that may occur when using a small One possible problematic scenario that may occur when using a small
Advertisement_Interval (refer to <xref target="sect-6.1"/>) is Advertisement_Interval (refer to <xref target="sect-6.1"/>) is
when a VRRP Router is generating more packets than it can transmit, an d a queue when a VRRP Router is generating more packets than it can transmit, an d a queue
builds up on the VRRP Router. When this occurs, it is possible that p ackets being builds up on the VRRP Router. When this occurs, it is possible that p ackets being
transmitted onto the VRRP-protected LAN could see a larger queueing transmitted onto the VRRP-protected LAN could see a larger queueing
delay than the smallest Advertisement_Interval. In this case, delay than the smallest Advertisement_Interval. In this case,
the Active_Down_Interval (refer to <xref target="sect-6.1"/>) may be s mall the Active_Down_Interval (refer to <xref target="sect-6.1"/>) may be s mall
enough that normal queuing enough that normal queuing
delays might cause a Backup Router to conclude that the Active Router is down, 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 and, hence, promote itself to Active Router. Very shortly afterwards, the
delayed VRRP packets from the original Active Router cause a switch ba ck to Backup delayed VRRP packets from the original Active Router cause the VRRP Ro uter to switch back to Backup
Router. Furthermore, this process can repeat many times per second, Router. Furthermore, this process can repeat many times per second,
causing a significant disruption of traffic. To mitigate this problem , causing a significant disruption of traffic. To mitigate this problem ,
giving VRRP packets priority on egress interface queues should be cons idered. giving VRRP packets priority on egress interface queues should be cons idered.
If the Active Router observes that this is occurring, it SHOULD log th e problem If the Active Router observes that this is occurring, it <bcp14>SHOULD </bcp14> log the problem
(subject to rate-limiting). (subject to rate-limiting).
</t> </t>
</section> </section>
</section> </section>
<section anchor="sect-3"> <section anchor="sect-3">
<name>VRRP Overview</name> <name>VRRP Overview</name>
<t> <t>
VRRP specifies an election protocol to provide the Virtual Router VRRP specifies an election protocol to provide the Virtual Router
function described earlier. All protocol messaging is performed function described earlier. All protocol messaging is performed
using either IPv4 or IPv6 multicast datagrams. Thus, the protocol can using either IPv4 or IPv6 multicast datagrams. Thus, the protocol can
operate over a variety of multiaccess LAN technologies supporting operate over a variety of multiaccess LAN technologies supporting
IPvX multicast. Each link of a VRRP Virtual Router has a single IPvX multicast. Each link of a VRRP Virtual Router has a single
well-known MAC address allocated to it. This document currently only well-known MAC address allocated to it. This document currently only
details the mapping to networks using an IEEE 802 48-bit MAC 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 address. The Virtual Router MAC address is used as the source in all
periodic VRRP messages sent by the Active Router to enable MAC periodic VRRP messages sent by the Active Router to enable MAC
learning by layer-2 bridges on an extended LAN.</t> learning by Layer 2 (L2) bridges on an extended LAN.</t>
<t> <t>
A Virtual Router is defined by its Virtual Router Identifier (VRID) 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 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. associate a Virtual Router with its real address on an interface.
The scope of each Virtual Router is restricted to a single LAN. A The scope of each Virtual Router is restricted to a single LAN. A
VRRP Router may be configured with additional Virtual Router mappings VRRP Router may be configured with additional Virtual Router mappings
and priority for Virtual Routers it is willing to back up. The and priority for Virtual Routers it is willing to back up. The
mapping between the VRID and its IPvX address(es) must be coordinated mapping between the VRID and its IPvX address(es) must be coordinated
among all VRRP Routers on a LAN. among all VRRP Routers on a LAN.
</t> </t>
skipping to change at line 568 skipping to change at line 558
<t> <t>
To minimize network traffic, only the Active Router for each Virtual Rout er To minimize network traffic, only the Active Router for each Virtual Rout er
sends periodic VRRP Advertisement messages. A Backup Router will not sends periodic VRRP Advertisement messages. A Backup Router will not
attempt to preempt the Active Router unless the Backup Router attempt to preempt the Active Router unless the Backup Router
has a higher priority. This has a higher priority. This
eliminates service disruption unless a more preferred path becomes eliminates service disruption unless a more preferred path becomes
available. It's also possible to administratively prohibit Active Route r available. It's also possible to administratively prohibit Active Route r
preemption attempts. The only exception is that a VRRP Router will preemption attempts. The only exception is that a VRRP Router will
always become the Active Router for any Virtual Router associated with always become the Active Router for any Virtual Router associated with
address(es) it owns. If the Active Router becomes unavailable, then the address(es) it owns. If the Active Router becomes unavailable, then the
highest-priority Backup Router will transition to Active Router highest-priority Backup Router will transition to the Active Router
after a short delay, providing a controlled transition of Virtual Router after a short delay, providing a controlled transition of Virtual Router
responsibility with minimal service interruption. responsibility with minimal service interruption.
</t> </t>
<t> <t>
The VRRP protocol design provides rapid transition from Backup Router to The VRRP protocol design provides rapid transition from the Backup Router
Active Router to minimize service interruption and incorporates to
the Active Router to minimize service interruption and incorporates
optimizations that reduce protocol complexity while guaranteeing optimizations that reduce protocol complexity while guaranteeing
controlled Active Router transition for typical operational scenarios. These controlled Active Router transition for typical operational scenarios. These
optimizations result in an election protocol with minimal runtime optimizations result in an election protocol with minimal runtime
state requirements, minimal active protocol states, and a single state requirements, minimal active protocol states, and a single
message type and sender. The typical operational scenarios are message type and sender. The typical operational scenarios are
defined to be two redundant routers and/or distinct path preferences defined to be two redundant routers and/or distinct path preferences
for each router. A side effect when these assumptions are violated, for each router. A side effect when these assumptions are violated,
i.e., more than two redundant paths with equal preference, is i.e., more than two redundant paths with equal preference, is
that duplicate packets may be forwarded for a brief period during that duplicate packets may be forwarded for a brief period during
Active Router election. However, the typical scenario assumptions are Active Router election. However, the typical scenario assumptions are
likely to cover the vast majority of deployments, loss of the Active likely to cover the vast majority of deployments, loss of the Active
Router is infrequent, and the expected duration for Active Router electi on Router is infrequent, and the expected duration for Active Router electi on
convergence is quite small (&lt; 4 seconds when using the default convergence is quite small (&lt; 4 seconds when using the default
Advertisement_Interval and configurable to &lt; 1/25 second). Thus, Advertisement_Interval and configurable to &lt; 1/25 second). Thus,
the VRRP optimizations represent significant simplifications in the VRRP optimizations represent significant simplifications in
the protocol design while incurring an insignificant probability of the protocol design while incurring an insignificant probability of
brief network disruption. brief network disruption.
</t> </t>
</section> </section>
<section anchor="sect-4"> <section anchor="sect-4">
<name>Sample Configurations</name> <name>Sample VRRP Networks</name>
<section anchor="sect-4.1"> <section anchor="sect-4.1">
<name>Sample Configuration 1</name> <name>Sample VRRP Network 1</name>
<t> <t>
The following figure shows a simple network with two VRRP Routers The following figure shows a simple network with two VRRP Routers
implementing one Virtual Router. implementing one Virtual Router.
</t> </t>
<figure>
<name>Sample VRRP Network 1</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-----------+ +-----------+ +-----------+ +-----------+
| Router-1 | | Router-2 | | Router-1 | | Router-2 |
|(AR VRID=1)| |(BR VRID=1)| |(AR VRID=1)| |(BR VRID=1)|
| | | | | | | |
VRID=1 +-----------+ +-----------+ VRID=1 +-----------+ +-----------+
IPvX A------>* *<---------IPvX B IPvX A------>* *<---------IPvX B
| | | |
| | | |
-------------+------------+--+-----------+-----------+-----------+ -------------+------------+--+-----------+-----------+-----------+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
Default Router | | | | Default Router | | | |
IPvX addresses ---> (IPvX A) (IPvX A) (IPvX A) (IPvX A) IPvX Addresses ---> (IPvX A) (IPvX A) (IPvX A) (IPvX A)
| | | | | | | |
IPvX H1->* IPvX H2->* IPvX H3->* IPvX H4->* IPvX H1->* IPvX H2->* IPvX H3->* IPvX H4->*
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 | | H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+
Legend: Legend:
--+---+---+-- = Ethernet --+---+---+-- = Ethernet
H = Host computer H = Host computer
AR = Active Router AR = Active Router
BR = Backup Router BR = Backup Router
skipping to change at line 630 skipping to change at line 621
| H1 | | H2 | | H3 | | H4 | | H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+
Legend: Legend:
--+---+---+-- = Ethernet --+---+---+-- = Ethernet
H = Host computer H = Host computer
AR = Active Router AR = Active Router
BR = Backup Router BR = Backup Router
* = IPvX Address: X is 4 everywhere in IPv4 case * = IPvX Address: X is 4 everywhere in IPv4 case
X is 6 everywhere in IPv6 case X is 6 everywhere in IPv6 case
(IPvX) = Default Router for hosts (IPvX) = Default Router for hosts
]]></artwork> ]]></artwork>
</figure>
<t> <t>
In the IPv4 case, i.e., IPvX is IPv4 everywhere in the figure, In the IPv4 case, i.e., IPvX is IPv4 everywhere in the figure,
each router is permanently assigned an IPv4 address on the LAN 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 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 each host installs a default route (learned through DHCPv4 or via a
configured static route) through one of the routers configured static route) through one of the routers
(in this example, they all use Router-1's IPv4 A). (in this example, they all use Router-1's IPv4 A).
</t> </t>
<t> <t>
In the IPv6 case, i.e., IPvX is IPv6 everywhere in the figure, each ro uter has its own In the IPv6 case, i.e., IPvX is IPv6 everywhere in the figure, each ro uter has its own
Link-Local IPv6 address on the LAN interface, and a link-local 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. IPv6 address per VRID that is shared with the other routers that serve the same VRID.
Each host learns a default route from Router Each host learns a default route from Router
Advertisements through one of the routers (in this example, they all Advertisements through one of the routers (in this example, they all
use Router-1's IPv6 Link-Local A). use Router-1's IPv6 Link-Local A).
</t> </t>
<t> <t>
In an IPv4 VRRP environment, each router supports reception and transm ission for In an IPv4 VRRP environment, each router supports reception and transm ission for
the exact same IPv4 address. Router-1 is said to be the IPv4 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 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 IPv4 B. A Virtual Router is then defined by associating a unique
skipping to change at line 670 skipping to change at line 661
Router is then defined by associating a unique identifier (the Router is then defined by associating a unique identifier (the
VRID) with the address owned by Router-1. VRID) with the address owned by Router-1.
</t> </t>
<t> <t>
Finally, in both the IPv4 and IPv6 cases, the VRRP protocol manages Finally, in both the IPv4 and IPv6 cases, the VRRP protocol manages
Virtual Router failover to a Backup Router. Virtual Router failover to a Backup Router.
</t> </t>
<t> <t>
The IPvX example above shows a Virtual Router configured to cover the 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 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 Active Router , with enabled on Router-1 for VRID=1, it will assert itself as the Active Ro uter, with
priority = 255, since it is the IPvX address owner for the Virtual 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 Router IPvX address. When VRRP is enabled on Router-2 for VRID=1, it will
transition to Backup Router, with priority = 100 (the default priority is transition to the Backup Router, with priority = 100 (the default prio rity is
100), since it is not the IPvX address owner. If Router-1 should fail , 100), since it is not the IPvX address owner. If Router-1 should fail ,
then the VRRP protocol will transition Router-2 to Active Router, temp orarily then the VRRP protocol will transition Router-2 to the Active Router, temporarily
taking over forwarding responsibility for IPvX A to provide taking over forwarding responsibility for IPvX A to provide
uninterrupted service to the hosts. uninterrupted service to the hosts.
</t> </t>
<t> <t>
Note that in both cases in this example, IPvX B is not backed up and i t Note that in both cases in this example, IPvX B is not backed up and i t
is only used by Router-2 as its interface address. In order to back u p is only used by Router-2 as its interface address. In order to back u p
IPvX B, a second Virtual Router must be configured. This is shown in IPvX B, a second Virtual Router must be configured. This is shown in
the next section. the next section.
</t> </t>
</section> </section>
<section anchor="sect-4.2"> <section anchor="sect-4.2">
<name>Sample Configuration 2</name> <name>Sample VRRP Network 2</name>
<t> <t>
The following figure shows a configuration with two Virtual Routers The following figure shows a configuration with two Virtual Routers
with the hosts splitting their traffic between them. with the hosts splitting their traffic between them.
</t> </t>
<figure>
<name>Sample VRRP Network 2</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-----------+ +-----------+ +-----------+ +-----------+
| Router-1 | | Router-2 | | Router-1 | | Router-2 |
|(AR VRID=1)| |(BR VRID=1)| |(AR VRID=1)| |(BR VRID=1)|
|(BR VRID=2)| |(AR VRID=2)| |(BR VRID=2)| |(AR VRID=2)|
VRID=1 +-----------+ +-----------+ VRID=2 VRID=1 +-----------+ +-----------+ VRID=2
IPvX A ----->* *<---------- IPvX B IPvX A ----->* *<---------- IPvX B
| | | |
| | | |
----------+-------------+-+-----------+-----------+-----------+ ----------+-------------+-+-----------+-----------+-----------+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
Default Router | | | | Default Router | | | |
IPvX addresses ---> (IPvX A) (IPvX A) (IPvX B) (IPvX B) IPvX Addresses ---> (IPvX A) (IPvX A) (IPvX B) (IPvX B)
| | | | | | | |
IPvX H1->* IPvX H2->* IPvX H3->* IPvX H4->* IPvX H1->* IPvX H2->* IPvX H3->* IPvX H4->*
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 | | H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+
Legend: Legend:
---+---+---+-- = Ethernet ---+---+---+-- = Ethernet
H = Host computer H = Host computer
AR = Active Router AR = Active Router
skipping to change at line 720 skipping to change at line 713
+-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+
Legend: Legend:
---+---+---+-- = Ethernet ---+---+---+-- = Ethernet
H = Host computer H = Host computer
AR = Active Router AR = Active Router
BR = Backup Router BR = Backup Router
* = IPvX Address: X is 4 everywhere in IPv4 case * = IPvX Address: X is 4 everywhere in IPv4 case
X is 6 everywhere in IPv6 case X is 6 everywhere in IPv6 case
(IPvX) = Default Router for hosts (IPvX) = Default Router for hosts
]]></artwork> ]]></artwork>
</figure>
<t> <t>
In the IPv4 example above, i.e., IPvX is IPv4 everywhere in the In the IPv4 example above, i.e., IPvX is IPv4 everywhere in the
figure, half of the hosts have configured a static default route throu gh figure, half of the hosts have configured a static default route throu gh
Router-1's IPv4 A, and half are using Router-2's IPv4 B. The configur ation Router-1's IPv4 A, and half are using Router-2's IPv4 B. The configur ation
of Virtual Router VRID=1 is exactly the same as in the first example of Virtual Router VRID=1 is exactly the same as in the first example
(see <xref target="sect-4.1"/>), and a second Virtual Router has been added to (see <xref target="sect-4.1"/>), and a second Virtual Router has been added to
cover the IPv4 address owned by Router-2 (VRID=2, IPv4_Address=B). In cover the IPv4 address owned by Router-2 (VRID=2, IPv4_Address=B). In
this case, Router-2 will assert itself as Active Router for VRID=2 whi le Router-1 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 will act as a Backup Router. This scenario demonstrates a deployment
providing load-splitting when both routers are available, while providing load-splitting when both routers are available, while
providing full redundancy for robustness. providing full redundancy for robustness.
</t> </t>
<t> <t>
In the IPv6 example above, i.e., IPvX is IPv6 everywhere in the In the IPv6 example above, i.e., IPvX is IPv6 everywhere in the
figure, half of the hosts are using a default route through 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 configur ation Router-1's IPv6 A, and half are using Router-2's IPv6 B. The configur ation
of Virtual Router VRID=1 is exactly the same as in the first example of Virtual Router VRID=1 is exactly the same as in the first example
(see <xref target="sect-4.1"/>), and a second Virtual Router has been added to (see <xref target="sect-4.1"/>), and a second Virtual Router has been added to
cover the IPv6 address owned by Router-2 (VRID=2, IPv6_Address=B). In cover the IPv6 address owned by Router-2 (VRID=2, IPv6_Address=B). In
this case, Router-2 will assert itself as Active Router for VRID=2 whi le Router-1 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 will act as a Backup Router. This scenario demonstrates a deployment
providing load-splitting when both routers are available, while providing load-splitting when both routers are available while
providing full redundancy for robustness. providing full redundancy for robustness.
</t> </t>
<t> <t>
Note that the details of load-balancing are out of scope of this Note that the details of load-balancing are out of scope of this
document. However, in a case where the servers need different document. However, in a case where the servers need different
weights, it may not make sense to rely on router advertisements alone weights, it may not make sense to rely on Router Advertisements alone
to balance the host traffic between the routers <xref target="RFC4311" />. to balance the host traffic between the routers <xref target="RFC4311" />.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sect-5"> <section anchor="sect-5">
<name>Protocol</name> <name>Protocol</name>
<t> <t>
The purpose of the VRRP Advertisement is to communicate to all VRRP Rout ers The purpose of the VRRP Advertisement is to communicate to all VRRP Rout ers
the priority, Max Advertisement Interval, and IPvX addresses of the Acti ve Router the priority, Maximum Advertisement Interval, and IPvX addresses of the Active Router
associated with the VRID. associated with the VRID.
</t> </t>
<t> <t>
When VRRP is protecting an IPv4 address, VRRP packets are sent When VRRP is protecting an IPv4 address, VRRP packets are sent
encapsulated in IPv4 packets. They are sent to the IPv4 multicast encapsulated in IPv4 packets. They are sent to the IPv4 multicast
address assigned to VRRP. address assigned to VRRP.
</t> </t>
<t> <t>
When VRRP is protecting an IPv6 address, VRRP packets are sent When VRRP is protecting an IPv6 address, VRRP packets are sent
encapsulated in IPv6 packets. They are sent to the IPv6 multicast encapsulated in IPv6 packets. They are sent to the IPv6 multicast
address assigned to VRRP. address assigned to VRRP.
</t> </t>
<section anchor="sect-5.1"> <section anchor="sect-5.1">
<name>VRRP Packet Format</name> <name>VRRP Packet Format</name>
<t> <t>
This section defines the format of the VRRP packet and the relevant This section defines the format of the VRRP packet and the relevant
fields in the IPvX header (in conjunction with the address family). fields in the IPvX header (in conjunction with the address family).
</t> </t>
<figure>
<name>IPv4/IPv6 VRRP Advertisement Packet Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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 | | IPv4 Fields or IPv6 Fields |
... ... ... ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority |IPvX Addr Count| |Version| Type | Virtual Rtr ID| Priority |IPvX Addr Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 800 skipping to change at line 796
+ + + +
| IPvX Address(es) | | IPvX Address(es) |
+ + + +
+ + + +
+ + + +
+ + + +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4/IPv6 VRRP Advertisement Packet Format
]]></artwork> ]]></artwork>
</figure>
<section anchor="sect-5.1.1"> <section anchor="sect-5.1.1">
<name>IPv4 Field Descriptions</name> <name>IPv4 Field Descriptions</name>
<section anchor="sect-5.1.1.1"> <section anchor="sect-5.1.1.1">
<name>Source Address</name> <name>Source Address</name>
<t> <t>
This is the primary IPv4 address of the interface from which the pa cket is being This is the primary IPv4 address of the interface from which the pa cket is being
sent. sent.
</t> </t>
</section> </section>
<section anchor="sect-5.1.1.2"> <section anchor="sect-5.1.1.2">
<name>Destination Address</name> <name>Destination Address</name>
<t> <t>
The IPv4 multicast address as assigned by the IANA for VRRP is: The IPv4 multicast address as assigned by the IANA for VRRP is:
</t> </t>
<t indent="4"> <t indent="4">
224.0.0.18 224.0.0.18
</t> </t>
<t> <t>
This is a link-local scope multicast address. Routers MUST NOT This is a link-local scope multicast address. Routers <bcp14>MUST NOT</bcp14>
forward a datagram with this destination address, regardless of it s forward a datagram with this destination address, regardless of it s
TTL. TTL.
</t> </t>
</section> </section>
<section anchor="sect-5.1.1.3"> <section anchor="sect-5.1.1.3">
<name>TTL</name> <name>TTL</name>
<t> <t>
The TTL MUST be set to 255. A VRRP Router receiving a packet with The TTL <bcp14>MUST</bcp14> be set to 255. A VRRP Router receiving
the TTL not equal to 255 MUST discard the packet <xref target="RFC a packet with
5082"/>. the TTL not equal to 255 <bcp14>MUST</bcp14> discard the packet <x
ref target="RFC5082"/>.
</t> </t>
</section> </section>
<section anchor="sect-5.1.1.4"> <section anchor="sect-5.1.1.4">
<name>Protocol</name> <name>Protocol</name>
<t> <t>
The IPv4 protocol number assigned by the IANA for VRRP is 112 The IPv4 protocol number assigned by the IANA for VRRP is 112
(decimal). (decimal).
</t> </t>
</section> </section>
</section> </section>
skipping to change at line 859 skipping to change at line 854
</section> </section>
<section anchor="sect-5.1.2.2"> <section anchor="sect-5.1.2.2">
<name>Destination Address</name> <name>Destination Address</name>
<t> <t>
The IPv6 multicast address assigned by the IANA for VRRP is: The IPv6 multicast address assigned by the IANA for VRRP is:
</t> </t>
<t indent="4"> <t indent="4">
ff02:0:0:0:0:0:0:12 ff02:0:0:0:0:0:0:12
</t> </t>
<t> <t>
This is a link-local scope multicast address. Routers MUST NOT This is a link-local scope multicast address. Routers <bcp14>MUST NOT</bcp14>
forward a datagram with this destination address, regardless of it s forward a datagram with this destination address, regardless of it s
Hop Limit. Hop Limit.
</t> </t>
</section> </section>
<section anchor="sect-5.1.2.3"> <section anchor="sect-5.1.2.3">
<name>Hop Limit</name> <name>Hop Limit</name>
<t> <t>
The Hop Limit MUST be set to 255. A VRRP Router receiving a packet The Hop Limit <bcp14>MUST</bcp14> be set to 255. A VRRP Router rec
with the Hop Limit not equal to 255 MUST discard the eiving a packet
with the Hop Limit not equal to 255 <bcp14>MUST</bcp14> discard th
e
packet <xref target="RFC5082"/>. packet <xref target="RFC5082"/>.
</t> </t>
</section> </section>
<section anchor="sect-5.1.2.4"> <section anchor="sect-5.1.2.4">
<name>Next Header</name> <name>Next Header</name>
<t> <t>
The IPv6 Next Header protocol assigned by the IANA for VRRP is 112 The IPv6 Next Header protocol assigned by the IANA for VRRP is 112
(decimal). (decimal).
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sect-5.2"> <section anchor="sect-5.2">
<name>VRRP Field Descriptions</name> <name>VRRP Field Descriptions</name>
<section anchor="sect-5.2.1"> <section anchor="sect-5.2.1">
<name>Version</name> <name>Version</name>
<t> <t>
The version field specifies the VRRP protocol version of this packet. The Version field specifies the VRRP protocol version of this packet.
This document defines version 3. This document defines version 3.
</t> </t>
</section> </section>
<section anchor="sect-5.2.2"> <section anchor="sect-5.2.2">
<name>Type</name> <name>Type</name>
<t> <t>
The Type field specifies the type of this VRRP packet. The only The Type field specifies the type of this VRRP packet. The only
packet type defined in this version of the protocol is: packet type defined in this version of the protocol is:
</t> </t>
<t indent="4"> <dl newline="false">
1 - ADVERTISEMENT <dt>1</dt><dd>- ADVERTISEMENT</dd>
</t> </dl>
<t> <t>
A packet with unknown type MUST be discarded. A packet with unknown type <bcp14>MUST</bcp14> be discarded.
</t> </t>
</section> </section>
<section anchor="sect-5.2.3"> <section anchor="sect-5.2.3">
<name>Virtual Rtr ID (VRID)</name> <name>Virtual Rtr ID (VRID)</name>
<t> <t>
The Virtual Rtr ID field identifies the Virtual Router for which this The Virtual Rtr ID field identifies the Virtual Router for which this
packet is reporting status. packet is reporting status.
</t> </t>
</section> </section>
<section anchor="sect-5.2.4"> <section anchor="sect-5.2.4">
<name>Priority</name> <name>Priority</name>
<t> <t>
The priority field specifies the sending VRRP Router's priority for The Priority field specifies sending the VRRP Router's priority for
the Virtual Router. Higher values indicate higher priority. This f ield the Virtual Router. Higher values indicate higher priority. This f ield
is an 8-bit unsigned integer field. is an 8-bit unsigned integer field.
</t> </t>
<t> <t>
The priority value for the VRRP Router that owns the IPvX address The priority value for the VRRP Router that owns the IPvX address
associated with the Virtual Router MUST be 255 (decimal). associated with the Virtual Router <bcp14>MUST</bcp14> be 255 (decim al).
</t> </t>
<t> <t>
VRRP Routers backing up a Virtual Router MUST use priority values VRRP Routers backing up a Virtual Router <bcp14>MUST</bcp14> use prio rity values
between 1-254 (decimal). The default priority value for VRRP Router s between 1-254 (decimal). The default priority value for VRRP Router s
backing up a Virtual Router is 100 (decimal). Refer to <xref target= "sect-8.3.2"/> backing up a Virtual Router is 100 (decimal). Refer to <xref target= "sect-8.3.2"/>
for recommendations on setting the priority. for recommendations on setting the priority.
</t> </t>
<t> <t>
The priority value zero (0) has special meaning, indicating that the The priority value zero (0) has special meaning, indicating that the
current Active Router has stopped participating in VRRP. This is us ed to current Active Router has stopped participating in VRRP. This is us ed to
trigger Backup Routers to quickly transition to Active Router withou t having trigger Backup Routers to quickly transition to the Active Router wi thout having
to wait for the current Active_Down_Interval (refer to <xref target= "sect-6.1"/>). to wait for the current Active_Down_Interval (refer to <xref target= "sect-6.1"/>).
</t> </t>
</section> </section>
<section anchor="sect-5.2.5"> <section anchor="sect-5.2.5">
<name>IPvX Addr Count</name> <name>IPvX Addr Count</name>
<t> <t>
This is the number of either IPv4 addresses or IPv6 addresses The IPvX Addr Count field is the number of either IPv4 addresses or I Pv6 addresses
contained in this VRRP advertisement. The minimum value is 1. contained in this VRRP advertisement. The minimum value is 1.
If the received count is 0, the VRRP advertisement MUST be ignored. If the received count is 0, the VRRP advertisement <bcp14>MUST</bcp1 4> be ignored.
</t> </t>
</section> </section>
<section anchor="sect-5.2.6"> <section anchor="sect-5.2.6">
<name>Reserve</name> <name>Reserve</name>
<t> <t>
This reserved field MUST be set to zero on transmission and ignored o n The Reserve field <bcp14>MUST</bcp14> be set to zero on transmission and ignored on
reception. reception.
</t> </t>
</section> </section>
<section anchor="sect-5.2.7"> <section anchor="sect-5.2.7">
<name>Maximum Advertisement Interval (Max Advertise Interval)</name> <name>Maximum Advertisement Interval (Max Advertise Interval)</name>
<t> <t>
The Maximum Advertisement Interval is a 12-bit field that indicates The Max Advertise Interval is a 12-bit field that indicates
the time interval (in centiseconds) between advertisements. The the time interval (in centiseconds) between advertisements. The
default is 100 centiseconds (1 second). default is 100 centiseconds (1 second).
</t> </t>
<t> <t>
Note that higher-priority Active Routers with slower transmission Note that higher-priority Active Routers with slower transmission
rates than their Backup Routers are unstable. This is because rates than their Backup Routers are unstable. This is because
lower-priority Backup Routers configured to faster rates could join the LAN and 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 decide they should be Active Routers before they have heard anything from
the higher-priority Active Router with a slower rate. When this hap pens, it the higher-priority Active Router with a slower rate. When this hap pens, it
is temporary, once the lower-priority node does hear from the higher -priority is temporary, i.e., once the lower-priority node does hear from the higher-priority
Active Router, it will relinquish Active Router status. Active Router, it will relinquish Active Router status.
</t> </t>
</section> </section>
<section anchor="sect-5.2.8"> <section anchor="sect-5.2.8">
<name>Checksum</name> <name>Checksum</name>
<t> <t>
The checksum field is used to detect data corruption in the VRRP The Checksum field is used to detect data corruption in the VRRP
message. message.
</t> </t>
<t> <t>
For both the IPv4 and IPv6 address families, the checksum is the 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 16-bit one's complement of the one's complement sum of the VRRP
message. For computing the checksum, message. For computing the checksum,
the checksum field is set to zero. See RFC1071 for more detail the Checksum field is set to zero. See <xref target="RFC1071"/> for
<xref target="RFC1071"/>. more details.
</t> </t>
<t> <t>
For the IPv4 address family, the checksum calculation only includes the For the IPv4 address family, the checksum calculation only includes the
VRRP message starting with the Version field and ending after the la st VRRP message starting with the Version field and ending after the la st
IPv4 address (refer to <xref target="sect-5.2"/>). IPv4 address (refer to <xref target="sect-5.2"/>).
</t> </t>
<t> <t>
For the IPv6 address family, the checksum calculation also includes For the IPv6 address family, the checksum calculation also includes
a prepended "pseudo-header" as defined in Section 8.1 of <xref targe a prepended "pseudo-header", as defined in <xref target="RFC8200" se
t="RFC8200"/>. ction="8.1" sectionFormat="of" />.
The next header field in the "pseudo-header" should be set to 112 (d The Next Header field in the "pseudo-header" should be set to 112 (d
ecimal) ecimal)
for VRRP. for VRRP.
</t> </t>
</section> </section>
<section anchor="sect-5.2.9"> <section anchor="sect-5.2.9">
<name>IPvX Address(es)</name> <name>IPvX Address(es)</name>
<t> <t>
This refers to one or more IPvX addresses associated with the Virtual This refers to one or more IPvX addresses associated with the Virtual
Router. The number of addresses included is specified in the Router. The number of addresses included is specified in the
"IPvX Addr Count" field. These fields are used for troubleshooting IPvX Addr Count field. These fields are used for troubleshooting
misconfigured routers. If more than one address is sent, it is misconfigured routers. If more than one address is sent, it is
recommended that all routers be configured to send these addresses i n recommended that all routers be configured to send these addresses i n
the same order to simplify comparisons. the same order to simplify comparisons.
</t> </t>
<t> <t>
For IPv4 addresses, this refers to one or more IPv4 addresses that For IPv4 addresses, this refers to one or more IPv4 addresses that
are backed up by the Virtual Router. are backed up by the Virtual Router.
</t> </t>
<t> <t>
For IPv6, the first address MUST be the IPv6 link-local address For IPv6, the first address <bcp14>MUST</bcp14> be the IPv6 link-loca l address
associated with the Virtual Router. associated with the Virtual Router.
</t> </t>
<t> <t>
This field contains either one or more IPv4 addresses, or one or more This field contains either one or more IPv4 addresses or one or more
IPv6 addresses. The address family of the addresses, IPv4 or IPv6 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 but not both, <bcp14>MUST</bcp14> be the same as the VRRP packet's I PvX header
address family. address family.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="state-machine"> <section anchor="state-machine">
<name>Protocol State Machine</name> <name>Protocol State Machine</name>
<section anchor="sect-6.1"> <section anchor="sect-6.1">
<name>Parameters Per Virtual Router</name> <name>Parameters per Virtual Router</name>
<dl newline="false" spacing="normal" indent="28"> <dl newline="false" spacing="normal" indent="28">
<dt>VRID</dt> <dt>VRID</dt>
<dd> <dd>
<t> <t>
Virtual Router Identifier. Configurable Virtual Router Identifier. Configurable
value in the range 1-255 (decimal). There value in the range 1-255 (decimal). There
is no default. is no default.
</t> </t>
</dd> </dd>
<dt>Priority</dt> <dt>Priority</dt>
<dd> <dd>
<t> <t>
Priority value to be used by this VRRP Priority value to be used by this VRRP
router in Active Router election for this Router in Active Router election for this
Virtual Router. The value of 255 Virtual Router. The value of 255
(decimal) is reserved for the router that (decimal) is reserved for the router that
owns the IPvX address associated with the owns the IPvX address associated with the
Virtual Router. The value of 0 (zero) is Virtual Router. The value of 0 (zero) is
reserved for the Active Router to reserved for the Active Router to
indicate it is relinquishing responsibility indicate it is relinquishing responsibility
for the Virtual Router. The range 1-254 for the Virtual Router. The range 1-254
(decimal) is available for VRRP Routers (decimal) is available for VRRP Routers
backing up the Virtual Router. Higher backing up the Virtual Router. Higher
values indicate higher priorities. The values indicate higher priorities. The
skipping to change at line 1063 skipping to change at line 1057
with this Virtual Router. Configured with this Virtual Router. Configured
list of addresses with no default. list of addresses with no default.
</t> </t>
</dd> </dd>
<dt>IPv6_Addresses</dt> <dt>IPv6_Addresses</dt>
<dd> <dd>
<t> <t>
One or more IPv6 addresses associated One or more IPv6 addresses associated
with this Virtual Router. Configured with this Virtual Router. Configured
list of addresses with no default. The first list of addresses with no default. The first
address MUST be the Link-Local address address <bcp14>MUST</bcp14> be the Link-Local address
associated with the Virtual Router. associated with the Virtual Router.
</t> </t>
</dd> </dd>
<dt>IPvX_Addresses</dt> <dt>IPvX_Addresses</dt>
<dd> <dd>
<t> <t>
Refer to either the IPv4 or IPv6 address associated Refer to either the IPv4 or IPv6 address associated
with this Virtual Router (see IPv4_Addresses and with this Virtual Router (see IPv4_Addresses and
IPv6_Addresses above). IPv6_Addresses above).
</t> </t>
</dd> </dd>
<dt>Advertisement_Interval</dt> <dt>Advertisement_Interval</dt>
<dd> <dd>
<t> <t>
Time interval between ADVERTISEMENTS Time interval between VRRP Advertisements
(centiseconds) sent by this Virtual Router. (centiseconds) sent by this Virtual Router.
Default is 100 centiseconds (1 second). Default is 100 centiseconds (1 second).
</t> </t>
</dd> </dd>
<dt>Active_Adver_Interval</dt> <dt>Active_Adver_Interval</dt>
<dd> <dd>
<t> <t>
Advertisement interval contained in Advertisement interval contained in
ADVERTISEMENTS received from the Active VRRP Advertisements received from the Active
Router (in centiseconds). This value is saved by Router (in centiseconds). This value is saved by
Virtual Routers in the Backup state and Virtual Routers in the Backup state and
used to compute Skew_Time (as specfied in <xref target="sect-8.3.2 "/>) used to compute Skew_Time (as specified in <xref target="sect-8.3. 2"/>)
and Active_Down_Interval. The initial value and Active_Down_Interval. The initial value
is the same as Advertisement_Interval. is the same as Advertisement_Interval.
</t> </t>
</dd> </dd>
<dt>Skew_Time</dt> <dt>Skew_Time</dt>
<dd> <dd>
<t> <t>
Time to skew Active_Down_Interval in Time to skew Active_Down_Interval in
centiseconds. Calculated as: centiseconds. Calculated as:
</t> </t>
skipping to change at line 1148 skipping to change at line 1143
addressed to the address owner's IPvX addressed to the address owner's IPvX
address as its own even if it is not the IPvX address as its own even if it is not the IPvX
address owner. The default is False. address owner. The default is False.
Deployments that rely on, for example, Deployments that rely on, for example,
pinging the address owner's IPvX address pinging the address owner's IPvX address
may wish to configure Accept_Mode to may wish to configure Accept_Mode to
True. True.
</t> </t>
<t> <t>
Note: IPv6 Neighbor Solicitations and Note: IPv6 Neighbor Solicitations and
Neighbor Advertisements MUST NOT be Neighbor Advertisements <bcp14>MUST NOT</bcp14> be
dropped when Accept_Mode is False. dropped when Accept_Mode is False.
</t> </t>
</dd> </dd>
<dt>Virtual_Router_MAC_Address</dt> <dt>Virtual_Router_MAC_Address</dt>
<dd> <dd>
<t> <t>
The MAC address used for the source MAC The MAC address used for the source MAC
address in VRRP advertisements and address in VRRP advertisements and
advertised in ARP/ND messages as advertised in ARP/ND messages as
the MAC address to use for IPvX_Addresses. the MAC address to use for IPvX_Addresses.
skipping to change at line 1184 skipping to change at line 1179
<dd> <dd>
<t> <t>
Timer that fires to trigger transmission of Timer that fires to trigger transmission of
a VRRP Advertisement based on the Advertisement_Interval (Active Ro uters only). a VRRP Advertisement based on the Advertisement_Interval (Active Ro uters only).
</t> </t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sect-6.3"> <section anchor="sect-6.3">
<name>State Transition Diagram</name> <name>State Transition Diagram</name>
<figure>
<name>State Transition Diagram</name>
<artwork><![CDATA[ <artwork><![CDATA[
+---------------+ +---------------+
+--------->| |<-------------+ +--------->| |<-------------+
| | Initialize | | | | Initialize | |
| +------| |----------+ | | +------| |----------+ |
| | +---------------+ | | | | +---------------+ | |
| | | | | | | |
| V V | | V V |
+---------------+ +---------------+ +---------------+ +---------------+
| |---------------------->| | | |---------------------->| |
| Active | | Backup | | Active | | Backup |
| |<----------------------| | | |<----------------------| |
+---------------+ +---------------+ +---------------+ +---------------+
]]></artwork> ]]></artwork>
</figure>
</section> </section>
<section anchor="sect-6.4"> <section anchor="sect-6.4">
<name>State Descriptions</name> <name>State Descriptions</name>
<t> <t>
In the state descriptions below, the state names are identified by In the state descriptions below, the state names are identified by
{state-name}, and the packets are identified by all-uppercase {state-name}, and the packets are identified by all-uppercase
characters. characters.
</t> </t>
<t> <t>
A VRRP Router implements an instance of the state machine for each A VRRP Router implements an instance of the state machine for each
Virtual Router in which it is participating. Virtual Router in which it is participating.
</t> </t>
<section anchor="sect-6.4.1"> <section anchor="sect-6.4.1">
<name>Initialize</name> <name>Initialize</name>
<t> <t>
The purpose of this state is to wait for a Startup event, that is, an The purpose of this state is to wait for a Startup event, that is, an
implementation-defined mechanism that initiates the protocol once it implementation-defined mechanism that initiates the protocol once it
has been configured. The configuration mechanism is out of scope fo r has been configured. The configuration mechanism is out of scope fo r
this specification. this specification.
</t> </t>
<artwork><![CDATA[ <t>If a Startup event is received, then:</t>
If a Startup event is received, then: <ul>
<li><t>If the Priority = 255, i.e., the router owns the IPvX
- If the Priority = 255, i.e., the router owns the IPvX address(es) associated with the Virtual Router, then:</t>
address(es) associated with the Virtual Router, then: <ul>
<li>Send an ADVERTISEMENT</li>
+ Send an ADVERTISEMENT <li><t>If the protected IPvX address is an IPv4 address, then:</t>
<ul>
+ If the protected IPvX address is an IPv4 address, then: <li>For each IPv4 address associated with the Virtual
Router, broadcast a gratuitous ARP message
* For each IPv4 address associated with the Virtual containing the Virtual Router MAC address and
Router, broadcast a gratuitous ARP message with the target link-layer address set to the
containing the Virtual Router MAC address and Virtual Router MAC address.</li>
with the target link-layer address set to the </ul></li>
Virtual Router MAC address. <li><t>else // IPv6</t>
<ul>
+ else // IPv6 <li>For each IPv6 address associated with the Virtual
Router, send an unsolicited ND Neighbor
* For each IPv6 address associated with the Virtual Advertisement with the Router Flag (R) set, the
Router, send an unsolicited ND Neighbor Solicited Flag (S) clear, the Override flag (O)
Advertisement with the Router Flag (R) set, the set, the target address set to the IPv6 address
Solicited Flag (S) clear, the Override flag (O) of the Virtual Router, and the target link-layer
set, the target address set to the IPv6 address address set to the Virtual Router MAC address.</li>
of the Virtual Router, and the target link-layer </ul></li>
address set to the Virtual Router MAC address. <li>endif // was protected address IPv4?</li>
<li>Set the Adver_Timer to Advertisement_Interval</li>
+ endif // was protected address IPv4? <li>Transition to the {Active} state</li>
</ul></li>
+ Set the Adver_Timer to Advertisement_Interval <li><t>else // Router is not the address owner</t>
<ul>
+ Transition to the {Active} state <li>Set the Active_Adver_Interval to Advertisement_Interval</li>
<li>Set the Active_Down_Timer to Active_Down_Interval</li>
- else // Router is not the address owner <li>Transition to the {Backup} state</li>
</ul></li>
+ Set Active_Adver_Interval to Advertisement_Interval <li>endif // was priority 255?</li>
</ul>
+ Set the Active_Down_Timer to Active_Down_Interval <t>endif // Startup event was received</t>
+ Transition to the {Backup} state
- endif // was priority 255?
endif // Startup event was received
]]></artwork>
</section> </section>
<section anchor="sect-6.4.2"> <section anchor="sect-6.4.2">
<name>Backup</name> <name>Backup</name>
<t> <t>
The purpose of the {Backup} state is to monitor the availability and The purpose of the {Backup} state is to monitor the availability and
state of the Active Router. The Solicited-Node multicast address state of the Active Router. The Solicited-Node multicast address
<xref target="RFC4291"/> is referenced in the pseudo-code below. <xref target="RFC4291"/> is referenced in the pseudocode below.
</t> </t>
<artwork><![CDATA[
While in 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 <t>While in the {Backup} state, a VRRP Router <bcp14>MUST</bcp14> do the followi
ng:</t>
+ If the protected IPvX address is an IPv4 address, then: <ul>
<li><t>If the protected IPvX address is an IPv4 address,
* For each IPv4 address associated with the Virtual then:</t>
Router, broadcast a gratuitous ARP message <ul>
containing the Virtual Router MAC address and <li><t>It <bcp14>MUST NOT</bcp14> respond to ARP requests for the IPv4
with the target link-layer address set to the address(es) associated with the Virtual Router.</t></li>
Virtual Router MAC address. </ul></li>
<li><t>else // protected address is IPv6</t>
+ else // IPv6 <ul>
<li>It <bcp14>MUST NOT</bcp14> respond to ND Neighbor Solicitation messages
* Compute and join the Solicited-Node multicast for the IPv6 address(es) associated with the Virtual Router.</li>
address [RFC4291] for the IPv6 address(es) <li>It <bcp14>MUST NOT</bcp14> send ND Router Advertisement messages
associated with the Virtual Router. for the Virtual Router.</li>
</ul></li>
* For each IPv6 address associated with the <li>endif // was protected address IPv4?</li>
Virtual Router, send an unsolicited ND Neighbor <li>It <bcp14>MUST</bcp14> discard packets with a destination link-layer
Advertisement with the Router Flag (R) set, the MAC address equal to the Virtual Router MAC address.</li>
Solicited Flag (S) clear, the Override flag (O) <li>It <bcp14>MUST NOT</bcp14> accept packets addressed to the IPvX
set, the target address set to the IPv6 address address(es) associated with the Virtual Router.</li>
of the Virtual Router, and the target link-layer <li><t>If a Shutdown event is received, then:</t>
address set to the Virtual Router MAC address. <ul>
<li>Cancel the Active_Down_Timer</li>
+ endif // was protected address IPv4? <li>Transition to the {Initialize} state</li>
</ul></li>
+ Set the Adver_Timer to Advertisement_Interval <li>endif // Shutdown event received</li>
<li><t>If the Active_Down_Timer fires, then:</t>
+ Transition to the {Active} state <ul>
<li><t>Send an ADVERTISEMENT</t></li>
- endif // Active_Down_Timer fired <li><t>If the protected IPvX address is an IPv4 address, then:</t>
<ul>
- If an ADVERTISEMENT is received, then: <li>For each IPv4 address associated with the Virtual
Router, broadcast a gratuitous ARP message
+ If the Priority in the ADVERTISEMENT is 0, then: containing the Virtual Router MAC address and
with the target link-layer address set to the
* Set the Active_Down_Timer to Skew_Time Virtual Router MAC address.</li>
</ul></li>
+ else // priority non-zero <li><t>else // IPv6</t>
<ul>
* If Preempt_Mode is False, or if the Priority in <li>Compute and join the Solicited-Node multicast
the ADVERTISEMENT is greater than or equal to the address <xref target="RFC4291"/> for the IPv6 address(es)
local Priority, then: associated with the Virtual Router.</li>
<li>For each IPv6 address associated with the
@ Set Active_Adver_Interval to Max Advertise Virtual Router, send an unsolicited ND Neighbor
Interval contained in the ADVERTISEMENT Advertisement with the Router Flag (R) set, the
Solicited Flag (S) clear, the Override flag (O)
@ Recompute the Skew_Time set, the target address set to the IPv6 address
of the Virtual Router, and the target link-layer
@ Recompute the Active_Down_Interval, address set to the Virtual Router MAC address.</li>
</ul></li>
@ Set the Active_Down_Timer to Active_Down_Interval <li>endif // was protected address IPv4?</li>
<li>Set the Adver_Timer to Advertisement_Interval</li>
* else // preempt was true and priority was less <li>Transition to the {Active} state</li>
than the local priority </ul></li>
<li>endif // Active_Down_Timer fired</li>
@ Discard the ADVERTISEMENT <li><t>If an ADVERTISEMENT is received, then:</t>
<ul>
* endif // preempt test <li><t>If the Priority in the ADVERTISEMENT is 0, then:</t>
<ul>
+ endif // was priority 0? <li>Set the Active_Down_Timer to Skew_Time</li>
</ul></li>
- endif // was advertisement received? <li><t>else // priority non-zero</t>
<ul><li><t>If Preempt_Mode is False, or if the Priority in
endwhile // Backup state the ADVERTISEMENT is greater than or equal to the
]]></artwork> local Priority, then:</t>
<ul>
<li>Set the Active_Adver_Interval to the Max Advertise
Interval contained in the ADVERTISEMENT</li>
<li>Recompute the Skew_Time</li>
<li>Recompute the Active_Down_Interval</li>
<li>Set the Active_Down_Timer to Active_Down_Interval</li>
</ul></li>
<li><t>else // preempt was true and priority was less
than the local priority</t>
<ul>
<li>Discard the ADVERTISEMENT</li>
</ul></li>
<li>endif // preempt test</li>
</ul></li>
<li>endif // was priority 0?</li>
</ul></li>
<li>endif // was advertisement received?</li>
</ul>
<t>endwhile // {Backup} state</t>
</section> </section>
<section anchor="sect-6.4.3"> <section anchor="sect-6.4.3">
<name>Active</name> <name>Active</name>
<t> <t>
While in the {Active} state, the router functions as the forwarding While in the {Active} state, the router functions as the forwarding
router for the IPvX address(es) associated with the Virtual Router. router for the IPvX address(es) associated with the Virtual Router.
</t> </t>
<t> <t>
Note that in the Active state, the Preempt_Mode Flag is not Note that in the {Active} state, the Preempt_Mode Flag is not
considered. considered.
</t> </t>
<artwork><![CDATA[
While in 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 <t>While in the {Active} state, a VRRP Router <bcp14>MUST</bcp14> do the
following:</t>
<ul>
<li><t>If the protected IPvX address is an IPv4 address, then:</t>
<ul>
<li>It <bcp14>MUST</bcp14> respond to ARP requests for the IPv4
address(es) associated with the Virtual Router.</li>
</ul></li>
<li><t>else // IPv6</t>
<ul>
<li>It <bcp14>MUST</bcp14> be a member of the Solicited-Node multicast
address for the IPv6 address(es) associated with the address for the IPv6 address(es) associated with the
Virtual Router. Virtual Router.</li>
<li>It <bcp14>MUST</bcp14> respond to ND Neighbor Solicitation messages (wit
+ It MUST respond to ND Neighbor Solicitation messages (with h
the Router Flag (R) set) for the IPv6 address(es) associated the Router Flag (R) set) for the IPv6 address(es) associated
with the Virtual Router. with the Virtual Router.</li>
<li>It <bcp14>MUST</bcp14> send ND Router Advertisements for the Virtual
+ It MUST send ND Router Advertisements for the Virtual Router.</li>
Router. <li><t>If Accept_Mode is False:</t>
<ul>
+ If Accept_Mode is False: MUST NOT drop IPv6 <li>It <bcp14>MUST NOT</bcp14> drop IPv6
Neighbor Solicitations and Neighbor Advertisements. Neighbor Solicitations and Neighbor Advertisements.</li>
</ul></li>
- endif // IPv4? </ul></li>
<li>endif // IPv4?</li>
- It MUST forward packets with a destination link-layer MAC <li>It <bcp14>MUST</bcp14> forward packets with a destination link-layer MAC
address equal to the Virtual Router MAC address. address equal to the Virtual Router MAC address.</li>
<li>It <bcp14>MUST</bcp14> accept packets addressed to the IPvX address(es)
- It MUST accept packets addressed to the IPvX address(es) associated with the Virtual Router if it is the IPvX
associated with the Virtual Router if it is the IPvX address owner or if Accept_Mode is True. Otherwise, it
address owner or if Accept_Mode is True. Otherwise, <bcp14>MUST NOT</bcp14> accept these packets.</li>
MUST NOT accept these packets. <li><t>If a Shutdown event is received, then:</t>
<ul>
- If a Shutdown event is received, then: <li>Cancel the Adver_Timer</li>
<li>Send an ADVERTISEMENT with Priority = 0</li>
+ Cancel the Adver_Timer <li>Transition to the {Initialize} state</li>
</ul></li>
+ Send an ADVERTISEMENT with Priority = 0 <li>endif // shutdown received</li>
<li><t>If the Adver_Timer fires, then:</t>
+ Transition to the {Initialize} state <ul>
<li>Send an ADVERTISEMENT</li>
- endif // shutdown received <li>Reset the Adver_Timer to Advertisement_Interval</li>
</ul></li>
- If the Adver_Timer fires, then: <li>endif // advertisement timer fired</li>
<li><t>If an ADVERTISEMENT is received, then:</t>
+ Send an ADVERTISEMENT <ul>
<li><t>If the Priority in the ADVERTISEMENT is 0, then:</t>
+ Reset the Adver_Timer to Advertisement_Interval <ul>
<li>Send an ADVERTISEMENT</li>
- endif // advertisement timer fired <li>Reset the Adver_Timer to Advertisement_Interval</li>
</ul></li>
- If an ADVERTISEMENT is received, then: <li><t>else // priority was non-zero</t>
<ul>
+ If the Priority in the ADVERTISEMENT is 0, then: <li><t>If the Priority in the ADVERTISEMENT is greater
than the local Priority or the Priority in the
* Send an ADVERTISEMENT ADVERTISEMENT is equal to the local Priority and
the primary IPvX address of the sender is greater
* Reset the Adver_Timer to Advertisement_Interval than the local primary IPvX address (based on an
unsigned integer comparison of the IPvX addresses in
+ else // priority was non-zero network byte order), then:</t>
<ul>
* If the Priority in the ADVERTISEMENT is greater <li>Cancel Adver_Timer</li>
than the local Priority or the Priority in the <li>Set the Active_Adver_Interval to the Max Advertise
ADVERTISEMENT is equal to the local Priority and Interval contained in the ADVERTISEMENT</li>
the primary IPvX Address of the sender is greater <li>Recompute the Skew_Time</li>
than the local primary IPvX Address (based on an <li>Recompute the Active_Down_Interval</li>
unsigned integer comparison of the IPvX addresses in <li>Set the Active_Down_Timer to Active_Down_Interval</li>
network-byte order), then: <li>Transition to the {Backup} state</li>
</ul></li>
@ Cancel Adver_Timer <li><t>else // new Active Router logic</t>
<ul>
@ Set Active_Adver_Interval to Max Advertise <li>Discard the ADVERTISEMENT</li>
Interval contained in the ADVERTISEMENT <li>Send an ADVERTISEMENT immediately to assert
the {Active} state to the sending VRRP Router and
@ Recompute the Skew_Time to update any learning bridges with the correct
Active VRRP Router path.</li>
@ Recompute the Active_Down_Interval </ul></li>
<li>endif // new Active Router detected</li>
@ Set Active_Down_Timer to Active_Down_Interval </ul></li>
<li>endif // was priority zero?</li>
@ Transition to the {Backup} state </ul></li>
<li>endif // advert received</li>
* else // new Active Router logic </ul>
@ Discard the ADVERTISEMENT
@ Send an ADVERTISEMENT immediately to assert
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 <t>endwhile // in {Active} state</t>
]]></artwork>
<t> <t>
Note: VRRP packets are transmitted with the Virtual Router MAC Note: VRRP packets are transmitted with the Virtual Router MAC
Address as the source MAC address to ensure that learning bridges address as the source MAC address to ensure that learning bridges
correctly determine the LAN segment to which the Virtual Router is correctly determine the LAN segment to which the Virtual Router is
attached. attached.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sect-7"> <section anchor="sect-7">
<name>Sending and Receiving VRRP Packets</name> <name>Sending and Receiving VRRP Packets</name>
<section anchor="sect-7.1"> <section anchor="sect-7.1">
<name>Receiving VRRP Packets</name> <name>Receiving VRRP Packets</name>
<t> <t>
The following functions must be performed when a VRRP packet is receiv ed: The following functions must be performed when a VRRP packet is receiv ed:
</t> </t>
<artwork><![CDATA[ <ul>
- If the received packet is an IPv4 packet, then: <li><t>If the received packet is an IPv4 packet, then:</t>
<ul>
+ It MUST verify that the IPv4 TTL is 255. <li>It <bcp14>MUST</bcp14> verify that the IPv4 TTL is 255.</li>
</ul></li>
- else // IPv6 VRRP packet received <li><t>else // IPv6 VRRP packet received</t>
<ul>
+ It MUST verify that the IPv6 Hop Limit is 255. <li>It <bcp14>MUST</bcp14> verify that the IPv6 Hop Limit is 255.</li>
</ul></li>
-endif <li>endif</li>
<li>It <bcp14>MUST</bcp14> verify that the VRRP version is 3.</li>
- It MUST verify that the VRRP Version is 3. <li>It <bcp14>MUST</bcp14> verify that the VRRP packet type is 1 (ADVERTISEMEN
T).</li>
- It MUST verify that the VRRP Packet Type is 1 (ADVERTISEMENT). <li>It <bcp14>MUST</bcp14> verify that the received packet contains the comple
te
- It MUST verify that the received packet contains the complete VRRP packet (including fixed fields and the IPvX address).</li>
VRRP packet (including fixed fields, and IPvX address). <li>It <bcp14>MUST</bcp14> verify the VRRP checksum.</li>
<li>It <bcp14>MUST</bcp14> verify that the VRID is configured on the receiving
- 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 interface and the local router is not the IPvX address
owner (Priority = 255 (decimal)). owner (Priority = 255 (decimal)).</li>
</ul>
If any one of the above checks fails, the receiver MUST discard <t>If any one of the above checks fails, the receiver <bcp14>MUST</bcp14> discar
the packet, SHOULD log the event (subject to rate-limiting), and d
MAY indicate via network management that an error occurred. the packet, <bcp14>SHOULD</bcp14> log the event (subject to rate-limiting), and
]]></artwork> <bcp14>MAY</bcp14> indicate via network management that an error occurred.</t>
<t> <t>
A receiver SHOULD also verify that the Max Advertise Interval A receiver <bcp14>SHOULD</bcp14> also verify that the Max Advertise In terval
in the received VRRP packet matches the Advertisement_Interval in the received VRRP packet matches the Advertisement_Interval
configured for the VRID. Instability can occur with differing interval s configured for the VRID. Instability can occur with differing interval s
(refer to <xref target="sect-5.2.7"/>). (refer to <xref target="sect-5.2.7"/>).
If this check fails, the receiver SHOULD log the event (subject to If this check fails, the receiver <bcp14>SHOULD</bcp14> log the event
rate-limiting) and MAY indicate via network management that a (subject to
rate-limiting) and <bcp14>MAY</bcp14> indicate via network management
that a
misconfiguration was detected. misconfiguration was detected.
</t> </t>
<t> <t>
A receiver MAY also verify that "IPvX Addr Count" and the list A receiver <bcp14>MAY</bcp14> also verify that "IPvX Addr Count" and t
of IPvX address(es) match the IPvX Address(es) configured for the VRID he 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 If this check fails, the receiver <bcp14>SHOULD</bcp14> log (subject t
and MAY indicate via network management that a misconfiguration was de o rate-limiting) the event
tected. and <bcp14>MAY</bcp14> indicate via network management that a misconfi
guration was detected.
</t> </t>
</section> </section>
<section anchor="sect-7.2"> <section anchor="sect-7.2">
<name>Transmitting VRRP Packets</name> <name>Transmitting VRRP Packets</name>
<t> <t>
The following operations MUST be performed when transmitting a VRRP The following operations <bcp14>MUST</bcp14> be performed when transmi tting a VRRP
packet: packet:
</t> </t>
<artwork><![CDATA[ <ul>
- Fill in the VRRP packet fields with the appropriate Virtual <li>Fill in the VRRP packet fields with the appropriate Virtual
Router configuration state Router configuration state</li>
<li>Compute the VRRP checksum</li>
- Compute the VRRP checksum <li>Set the source MAC address to the Virtual Router MAC address</li>
<li><t>If the protected address is an IPv4 address, then:</t>
- Set the source MAC address to the Virtual Router MAC Address <ul>
<li>Set the source IPv4 address to the interface's primary IPv4
- If the protected address is an IPv4 address, then: address</li>
</ul></li>
+ Set the source IPv4 address to the interface's primary IPv4 <li><t>else // IPv6</t>
address <ul>
<li>Set the source IPv6 address to the interface's link-local
- else // IPv6 IPv6 address</li>
</ul></li>
+ Set the source IPv6 address to the interface's link-local <li>endif</li>
IPv6 address <li>Set the IPvX protocol to VRRP</li>
<li>Send the VRRP packet to the VRRP IPvX multicast group</li>
- endif </ul>
- Set the IPvX protocol to VRRP
- Send the VRRP packet to the VRRP IPvX multicast group
]]></artwork>
<t> <t>
Note: VRRP packets are transmitted with the Virtual Router MAC Note: VRRP packets are transmitted with the Virtual Router MAC
address as the source MAC address to ensure that learning bridges address as the source MAC address to ensure that learning bridges
correctly determine the LAN segment to which the Virtual Router is correctly determine the LAN segment to which the Virtual Router is
attached. attached.
</t> </t>
</section> </section>
<section anchor="sect-7.3"> <section anchor="sect-7.3">
<name>Virtual Router MAC Address</name> <name>Virtual Router MAC Address</name>
<t> <t>
The Virtual Router MAC address associated with a Virtual Router is an The Virtual Router MAC address associated with a Virtual Router is an
IEEE 802 MAC Address <xref target="I-D.ietf-intarea-rfc7042bis"/> in t he IEEE 802 MAC address <xref target="RFC9542"/> in the
following format: following format:
</t> </t>
<t> <t>
IPv4 case: 00-00-5E-00-01-{VRID} (in hex, in Internet-standard bit- IPv4 case: 00-00-5E-00-01-{VRID} (in hex, in network byte order)
order)
</t> </t>
<t> <t>
The first three octets are derived from the IANA's Organizational The first three octets are derived from the IANA's Organizationally
Unique Identifier (OUI). The next two octets (00-01) indicate the Unique Identifier (OUI). The next two octets (00-01) indicate the
address block assigned to the VRRP protocol for the IPv4 protocol. address block assigned to the VRRP protocol for the IPv4 protocol.
{VRID} is the Virtual Router Identifier. This mapping provides {VRID} is the Virtual Router Identifier. This mapping provides
for up to 255 IPv4 VRRP Routers on a LAN. for up to 255 IPv4 VRRP Routers on a LAN.
</t> </t>
<t> <t>
IPv6 case: 00-00-5E-00-02-{VRID} (in hex, in Internet-standard bit- IPv6 case: 00-00-5E-00-02-{VRID} (in hex, in network byte order)
order)
</t> </t>
<t> <t>
The first three octets are derived from the IANA's OUI. The next two 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 protoco l for octets (00-02) indicate the address block assigned to the VRRP protoco l for
the IPv6 protocol. {VRID} is the Virtual Router Identifier. This the IPv6 protocol. {VRID} is the Virtual Router Identifier. This
mapping provides for up to 255 IPv6 VRRP Routers on a LAN. mapping provides for up to 255 IPv6 VRRP Routers on a LAN.
</t> </t>
</section> </section>
<section anchor="sect-7.4"> <section anchor="sect-7.4">
<name>IPv6 Interface Identifiers</name> <name>IPv6 Interface Identifiers</name>
<t> <t>
<xref target="RFC8064"/> specifies that <xref target="RFC7217"/> be us ed <xref target="RFC8064"/> specifies that <xref target="RFC7217"/> be us ed
as the default scheme for generating stable address in IPv6 Stateless as the default scheme for generating a stable address in IPv6 Stateles s
Address Autoconfiguration (SLAAC) <xref target="RFC4862"/>. Address Autoconfiguration (SLAAC) <xref target="RFC4862"/>.
The Virtual Router MAC MUST NOT be used for the Net_Iface parameter us ed The Virtual Router MAC <bcp14>MUST NOT</bcp14> be used for the Net_Ifa ce parameter used
in the Interface Identifier (IID) derivation algorithms in in the Interface Identifier (IID) derivation algorithms in
<xref target="RFC7217"/> and <xref target="RFC8981"/>. <xref target="RFC7217"/> and <xref target="RFC8981"/>.
</t> </t>
<t> <t>
Similarly, the Virtual Router MAC MUST NOT be used for the Net_Iface p
arameter
used for the Interface Identifier (IID) derivation algorithms in
<xref target="RFC7217"/> and <xref target="RFC8981"/>.
</t>
<t>
This VRRP specification describes how to advertise and resolve the This VRRP specification describes how to advertise and resolve the
VRRP Router's IPv6 link-local address and other associated IPv6 VRRP Router's IPv6 link-local address and other associated IPv6
addresses into the Virtual Router MAC address. addresses into the Virtual Router MAC address.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sect-8"> <section anchor="sect-8">
<name>Operational Issues</name> <name>Operational Issues</name>
<section anchor="sect-8.1"> <section anchor="sect-8.1">
<name>IPv4</name> <name>IPv4</name>
<section anchor="sect-8.1.1"> <section anchor="sect-8.1.1">
<name>ICMP Redirects</name> <name>ICMP Redirects</name>
<t> <t>
ICMP redirects can be used normally when VRRP is running among a ICMP redirects can be used normally when VRRP is running among a
group of routers. This allows VRRP to be used in environments where group of routers. This allows VRRP to be used in environments where
the topology is not symmetric. the topology is not symmetric.
</t> </t>
<t> <t>
The IPv4 source address of an ICMP redirect should be the address The IPv4 source address of an ICMP redirect should be the address
that the end-host used when making its next-hop routing decision. I f that the end-host used when making its next-hop routing decision. I f
a VRRP Router is acting as Active Router for Virtual Router(s) conta ining a VRRP Router is acting as the Active Router for Virtual Router(s) c ontaining
address(es) it does not own, then it must determine to which Virtual address(es) it does not own, then it must determine to which Virtual
Router the packet was sent when selecting the redirect source Router the packet was sent when selecting the redirect source
address. One method to deduce the Virtual Router used is to examine address. One method to deduce the Virtual Router used is to examine
the destination MAC address in the packet that triggered the the destination MAC address in the packet that triggered the
redirect. redirect.
</t> </t>
<t> <t>
It may be useful to disable redirects for specific cases where VRRP 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 is being used to load-share traffic among a number of routers in a
symmetric topology. symmetric topology.
</t> </t>
</section> </section>
<section anchor="sect-8.1.2"> <section anchor="sect-8.1.2">
<name>Host ARP Requests</name> <name>Host ARP Requests</name>
<t> <t>
When a host sends an ARP request for one of the Virtual Router IPv4 When a host sends an ARP request for one of the Virtual Router IPv4
addresses, the Active Router MUST respond to the ARP request addresses, the Active Router <bcp14>MUST</bcp14> respond to the ARP request
with an ARP response that indicates the Virtual Router MAC address f or the with an ARP response that indicates the Virtual Router MAC address f or the
Virtual Router. Note that the source address of the Ethernet frame Virtual Router. Note that the source address of the Ethernet frame
of this ARP response is the physical MAC address of the physical of this ARP response is the physical MAC address of the physical
router. The Active Router MUST NOT respond with its physical router. The Active Router <bcp14>MUST NOT</bcp14> respond with its physical
MAC address in the ARP response. This allows the host to always MAC address in the ARP response. This allows the host to always
use the same MAC address regardless of the current Active Router. use the same MAC address, regardless of the current Active Router.
</t> </t>
<t> <t>
When a VRRP Router restarts or boots, it SHOULD NOT send any ARP When a VRRP Router restarts or boots, it <bcp14>SHOULD NOT</bcp14> s end any ARP
messages using its physical MAC address for an IPv4 address for messages using its physical MAC address for an IPv4 address for
which it is the IPv4 Address Owner (as defined in <xref target="sect -1.7"/>), which it is the IPv4 address owner (as defined in <xref target="sect -1.7"/>),
and it should only send ARP messages that include Virtual Router MAC addresses. and it should only send ARP messages that include Virtual Router MAC addresses.
</t> </t>
<t> <t>
This entails the following: This entails the following:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
When configuring an interface, Active Routers When configuring an interface, Active Routers
SHOULD broadcast a gratuitous ARP message containing the Virtual <bcp14>SHOULD</bcp14> broadcast a gratuitous ARP message containin g the Virtual
Router MAC address for each IPv4 address on that interface. Router MAC address for each IPv4 address on that interface.
</li> </li>
<li> <li>
At system boot, when initializing interfaces for VRRP operation, At system boot, when initializing interfaces for VRRP operation,
gratuitous ARP messages MUST be delayed until both the gratuitous ARP messages <bcp14>MUST</bcp14> be delayed until both the
IPv4 address and the Virtual Router MAC address are configured. IPv4 address and the Virtual Router MAC address are configured.
</li> </li>
<li> <li>
When, for example, SSH access to a particular VRRP Router is When, for example, Secure Shell (SSH) access to a particular VRRP
required, an IPv4 address known to belong to that router SHOULD be Router is
required, an IPv4 address known to belong to that router <bcp14>SH
OULD</bcp14> be
used. used.
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="sect-8.1.3"> <section anchor="sect-8.1.3">
<name>Proxy ARP</name> <name>Proxy ARP</name>
<t> <t>
If Proxy ARP is to be used on a VRRP Router, then the VRRP Router 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 <bcp14>MUST</bcp14> advertise the Virtual Router MAC address in the Proxy ARP
message. Doing otherwise could cause hosts to learn the real MAC message. Doing otherwise could cause hosts to learn the real MAC
address of the VRRP Router. address of the VRRP Router.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sect-8.2"> <section anchor="sect-8.2">
<name>IPv6</name> <name>IPv6</name>
<section anchor="sect-8.2.1"> <section anchor="sect-8.2.1">
<name>ICMPv6 Redirects</name> <name>ICMPv6 Redirects</name>
<t> <t>
ICMPv6 redirects can be used normally when VRRP is running among a ICMPv6 redirects can be used normally when VRRP is running among a
group of routers <xref target="RFC4443"/>. This allows VRRP to be u sed in group of routers <xref target="RFC4443"/>. This allows VRRP to be u sed in
environments where the topology is not symmetric, e.g., the VRRP environments where the topology is not symmetric, e.g., the VRRP
routers do not connect to the same destinations. Routers do not connect to the same destinations.
</t> </t>
<t> <t>
The IPv6 source address of an ICMPv6 redirect SHOULD be the address The IPv6 source address of an ICMPv6 redirect <bcp14>SHOULD</bcp14> be the address
that the end-host used when making its next-hop routing decision. I f that the end-host used when making its next-hop routing decision. I f
a VRRP Router is acting as Active Router for Virtual Router(s) conta ining a VRRP Router is acting as the Active Router for Virtual Router(s) c ontaining
address(es) it does not own, then it has to determine to which Virtu al address(es) it does not own, then it has to determine to which Virtu al
Router the packet was sent when selecting the redirect source Router the packet was sent when selecting the redirect source
address. A method to deduce the Virtual Router used is to examine address. A method to deduce the Virtual Router used is to examine
the destination MAC address in the packet that triggered the the destination MAC address in the packet that triggered the
redirect. redirect.
</t> </t>
</section> </section>
<section anchor="sect-8.2.2"> <section anchor="sect-8.2.2">
<name>ND Neighbor Solicitation</name> <name>ND Neighbor Solicitation</name>
<t> <t>
When a host sends an ND Neighbor Solicitation message for a Virtual When a host sends an ND Neighbor Solicitation message for a Virtual
Router IPv6 address, the Active Router MUST respond to the ND Router IPv6 address, the Active Router <bcp14>MUST</bcp14> respond t o the ND
Neighbor Solicitation message with the Virtual Router MAC address fo r the Neighbor Solicitation message with the Virtual Router MAC address fo r the
Virtual Router. The Active Router MUST NOT respond with its Virtual Router. The Active Router <bcp14>MUST NOT</bcp14> respond w ith its
physical MAC address. This allows the host to always use the same physical MAC address. This allows the host to always use the same
MAC address regardless of the current Active Router. MAC address, regardless of the current Active Router.
</t> </t>
<t> <t>
When an Active Router sends an ND Neighbor Solicitation When an Active Router sends an ND Neighbor Solicitation
message for a host's IPv6 address, the Active Router MUST message for a host's IPv6 address, the Active Router <bcp14>MUST</bc p14>
include the Virtual Router MAC address for the Virtual Router if it sends a include the Virtual Router MAC address for the Virtual Router if it sends a
source link-layer address option in the neighbor solicitation source link-layer address option in the Neighbor Solicitation
message. It MUST NOT use its physical MAC address in the source message. It <bcp14>MUST NOT</bcp14> use its physical MAC address in
the source
link-layer address option. link-layer address option.
</t> </t>
<t> <t>
When a VRRP Router restarts or boots, it SHOULD NOT send any ND When a VRRP Router restarts or boots, it <bcp14>SHOULD NOT</bcp14> s end any ND
messages with its physical MAC address for the IPv6 address it owns 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. and it should only send ND messages that include Virtual Router MAC addresses.
</t> </t>
<t> <t>
This entails the following:</t> This entails the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
When configuring an interface, Active Routers When configuring an interface, Active Routers
SHOULD send an unsolicited ND Neighbor Advertisement message <bcp14>SHOULD</bcp14> send an unsolicited ND Neighbor Advertisemen t message
containing the Virtual Router MAC address for the IPv6 address on containing the Virtual Router MAC address for the IPv6 address on
that interface. that interface.
</li> </li>
<li> <li>
At system boot, when initializing interfaces for VRRP operation, At system boot, when initializing interfaces for VRRP operation,
all ND Router and Neighbor Advertisements and Solicitation all ND Router Advertisements, ND Neighbor Advertisements, and ND N
messages MUST be delayed until both the IPv6 address and the eighbor Solicitation
messages <bcp14>MUST</bcp14> be delayed until both the IPv6 addres
s and the
Virtual Router MAC address are configured. Virtual Router MAC address are configured.
</li> </li>
</ul> </ul>
<t> <t>
Note that on a restarting Active Router where the VRRP protected Note that on a restarting Active Router where the VRRP protected
address is an interface address, i.e., the address owner, Duplicate address is an interface address, i.e., the address owner, Duplicate
Address Detection may fail, as the Backup Router MAY answer Address Detection may fail, as the Backup Router <bcp14>MAY</bcp14> answer
that it owns the address. One solution is to not run Duplicate that it owns the address. One solution is to not run Duplicate
Address Detection in this case. Address Detection in this case.
</t> </t>
</section> </section>
<section anchor="sect-8.2.3"> <section anchor="sect-8.2.3">
<name>Router Advertisements</name> <name>Router Advertisements</name>
<t> <t>
When a Backup VRRP Router has become Active Router for a Virtual Rou ter, it When a Backup VRRP Router has become the Active Router for a Virtual Router, it
is responsible for sending Router Advertisements for the Virtual is responsible for sending Router Advertisements for the Virtual
Router as specified in <xref target="sect-6.4.3"/>. The Backup Rout ers MUST be Router, as specified in <xref target="sect-6.4.3"/>. The Backup Rou ters <bcp14>MUST</bcp14> be
configured to send the same Router Advertisement options as the configured to send the same Router Advertisement options as the
address owner. address owner.
</t> </t>
<t> <t>
Router Advertisement options that advertise special services, e.g., Router Advertisement options that advertise special services, e.g.,
Home Agent Information Option, that are present in the address owner Home Agent Information Option, that are present in the address owner
SHOULD NOT be sent by the address owner unless the Backup Routers ar e <bcp14>SHOULD NOT</bcp14> be sent by the address owner unless the Ba ckup Routers are
prepared to assume these services in full and have a complete and prepared to assume these services in full and have a complete and
synchronized database for this service. synchronized database for this service.
</t> </t>
</section> </section>
<section anchor="sect-8.2.4"> <section anchor="sect-8.2.4">
<name>Unsolicited Neighbor Advertisements</name> <name>Unsolicited Neighbor Advertisements</name>
<t> <t>
A VRRP Router acting as either an IPv6 Active Router or Backup Route r, SHOULD A VRRP Router acting as either an IPv6 Active Router or Backup Route r <bcp14>SHOULD</bcp14>
accept Unsolicited Neighbor Advertisements and update the correspond ing accept Unsolicited Neighbor Advertisements and update the correspond ing
neighbor cache <xref target="RFC4861"/>. Since these are sent to the neighbor cache <xref target="RFC4861"/>. Since these are sent to the
IPv6 all-nodes multicast address (ff02::1) <xref target="RFC4861"/> or the IPv6 all-nodes multicast address (ff02::1) <xref target="RFC4861"/> or the
IPv6 all-routers multicast address (ff02::2), they will be received. Unsolicited IPv6 all-routers multicast address (ff02::2), they will be received. Unsolicited
Neighbor Advertisements are sent both in the case where the link-lev el addresses Neighbor Advertisements are sent both in the case where the link-lev el addresses
change <xref target="RFC4861"/> and for gratuitous neighbor discover y by first hop change <xref target="RFC4861"/> and for gratuitous neighbor discover y by first-hop
routers <xref target="RFC9131"/>. Additional configuration may be re quired in order routers <xref target="RFC9131"/>. Additional configuration may be re quired in order
for Unsolicited Neighbor Advertisements to update the corresponding neighbor cache. for Unsolicited Neighbor Advertisements to update the corresponding neighbor cache.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sect-8.3"> <section anchor="sect-8.3">
<name>IPvX</name> <name>IPvX</name>
<section anchor="sect-8.3.1"> <section anchor="sect-8.3.1">
<name>Potential Forwarding Loop</name> <name>Potential Forwarding Loop</name>
<t> <t>
If it is not the address owner, a VRRP Router SHOULD NOT forward If it is not the address owner, a VRRP Router <bcp14>SHOULD NOT</bcp
packets addressed to the IPvX address for which it becomes Active Ro 14> forward
uter. packets addressed to the IPvX address for which it becomes the Activ
e Router.
Forwarding these packets would result in unnecessary traffic. Also, Forwarding these packets would result in unnecessary traffic. Also,
in the case of LANs that receive packets they transmit, this can res ult in the case of LANs that receive packets they transmit, this can res ult
in a forwarding loop that is only terminated when the IPvX TTL expir es. in a forwarding loop that is only terminated when the IPvX TTL expir es.
</t> </t>
<t> <t>
One mechanism for VRRP Routers to avoid these forwarding loops is to add/delete 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 a host Drop Route for each non-owned IPvX address when transitioning
to/from Active state. to/from the Active state.
</t> </t>
</section> </section>
<section anchor="sect-8.3.2"> <section anchor="sect-8.3.2">
<name>Recommendations Regarding Setting Priority Values</name> <name>Recommendations Regarding Setting Priority Values</name>
<t> <t>
A priority value of 255 designates a particular router as the "IPvX address owner" 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 s tart up, preempt all for the VRID. VRRP Routers with priority 255 will, as soon as they s tart up, preempt all
lower-priority routers. For a VRID, only a single VRRP Router on th e link SHOULD be lower-priority routers. For a VRID, only a single VRRP Router on th e link <bcp14>SHOULD</bcp14> be
configured with priority 255. If multiple VRRP Routers advertising p riority 255 are configured with priority 255. If multiple VRRP Routers advertising p riority 255 are
detected, the condition SHOULD be logged (subject to rate-limiting). If no VRRP Router detected, the condition <bcp14>SHOULD</bcp14> be logged (subject to rate-limiting). If no VRRP Router
has this priority, and preemption is disabled, then no preemption wi ll occur. has this priority, and preemption is disabled, then no preemption wi ll occur.
</t> </t>
<t> <t>
In order to avoid two or more Backup Routers simultaneously becoming Active Routers after 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 Router the previous Active Router fails or is shut down, all Virtual Router
s SHOULD be configured s <bcp14>SHOULD</bcp14> be configured
with different priorities, and with sufficient differences in priori with different priorities and with sufficient differences in the pri
ty so that lower orities so that lower
priority Backup Routers do not transition to Active state before rec priority Backup Routers do not transition to the Active state before
eiving an advertisement receiving an advertisement
from the highest priority Backup Router following it transitioning t from the highest priority Backup Router when it transitions to the A
o Active Router. If ctive Router. If
multiple VRRP Routers advertising the same priority are detected, th multiple VRRP Routers advertising the same priority are detected, th
is condition MAY is condition <bcp14>MAY</bcp14>
be logged as a warning (subject to rate-limiting). be logged as a warning (subject to rate-limiting).
</t> </t>
<t> <t>
Since the Skew_Time is reduced as priority is increased, faster Since the Skew_Time is reduced as the priority is increased, faster
convergence can be obtained by using a higher priority for the prefe rred convergence can be obtained by using a higher priority for the prefe rred
Backup Router. However, with multiple Backup Routers, the priorities should have Backup Router. However, with multiple Backup Routers, the priorities should have
sufficient differences as previously recommended. sufficient differences, as previously recommended.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sect-8.4"> <section anchor="sect-8.4">
<name>VRRPv3 and VRRPv2 Interoperation</name> <name>VRRPv3 and VRRPv2 Interoperation</name>
<section anchor="sect-8.4.1"> <section anchor="sect-8.4.1">
<name>Assumptions</name> <name>Assumptions</name>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
VRRPv2 and VRRPv3 interoperation is optional. VRRPv2 and VRRPv3 interoperation is optional.
skipping to change at line 1869 skipping to change at line 1813
Mixing VRRPv2 and VRRPv3 should only be done when transitioning Mixing VRRPv2 and VRRPv3 should only be done when transitioning
from VRRPv2 to VRRPv3. Mixing the two versions should not be from VRRPv2 to VRRPv3. Mixing the two versions should not be
considered a permanent solution. considered a permanent solution.
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="sect-8.4.2"> <section anchor="sect-8.4.2">
<name>VRRPv3 Support of VRRPv2 Interoperation</name> <name>VRRPv3 Support of VRRPv2 Interoperation</name>
<t> <t>
As mentioned above, this support is intended for upgrade scenarios As mentioned above, this support is intended for upgrade scenarios
and is NOT RECOMMENDED for permanent deployments. and is <bcp14>NOT RECOMMENDED</bcp14> for permanent deployments.
</t> </t>
<t> <t>
An implementation MAY implement a configuration flag that tells it t o An implementation <bcp14>MAY</bcp14> implement a configuration flag that tells it to
listen for and send both VRRPv2 and VRRPv3 advertisements. listen for and send both VRRPv2 and VRRPv3 advertisements.
</t> </t>
<t> <t>
When a Virtual Router is configured this way and is the Active Route r, it When a Virtual Router is configured this way and is the Active Route r, it
MUST send both types at the configured rate, even if sub-second. <bcp14>MUST</bcp14> send both types at the configured rate, even if it is sub-second.
</t> </t>
<t> <t>
When a Virtual Router is configured this way and is the Backup Route r, it When a Virtual Router is configured this way and is the Backup Route r, it
MUST time out based on the rate advertised by the Active Router. In <bcp14>MUST</bcp14> time out based on the rate advertised by the Act
the ive Router. In the
case of a VRRPv2 Active Router, this means it MUST translate the tim case of a VRRPv2 Active Router, this means it <bcp14>MUST</bcp14> tr
eout anslate the timeout
value it receives (in seconds) into centiseconds. Also, a Backup value it receives (in seconds) into centiseconds. Also, a Backup
Router SHOULD ignore VRRPv2 advertisements from the current Active R Router <bcp14>SHOULD</bcp14> ignore VRRPv2 advertisements from the c
outer urrent Active Router
if it is also receiving VRRPv3 packets from it. It MAY report when if it is also receiving VRRPv3 packets from it. It <bcp14>MAY</bcp1
a VRRPv3 4> report when a VRRPv3
Active Router is not sending VRRPv2 packets as this suggests they do Active Router is not sending VRRPv2 packets, as this suggests they d
n't on't
agree on whether they're supporting VRRPv2 interoperation. agree on whether they're supporting VRRPv2 interoperation.
</t> </t>
<section anchor="sect-8.4.3"> <section anchor="sect-8.4.3">
<name>Interoperation Considerations</name> <name>Interoperation Considerations</name>
<section anchor="sect-8.4.3.1"> <section anchor="sect-8.4.3.1">
<name>Slow, High-Priority Active Routers</name> <name>Slow, High-Priority Active Routers</name>
<t> <t>
See also <xref target="sect-5.2.7"/>, See also <xref target="sect-5.2.7"/>,
"Maximum Advertisement Interval (Max Advertise Interval)". "Maximum Advertisement Interval (Max Advertise Interval)".
</t> </t>
<t> <t>
The VRRPv2 Active Router interacting with a sub-second VRRPv3 Ba ckup The VRRPv2 Active Router interacting with a sub-second VRRPv3 Ba ckup
router is the most important example of this. Router is the most important example of this.
</t> </t>
<t> <t>
A VRRPv2 implementation SHOULD NOT be given a higher priority th A VRRPv2 implementation <bcp14>SHOULD NOT</bcp14> be given a hig
an a her priority than a
VRRPv2/VRRPv3 implementation with which it is interoperating if VRRPv2 or VRRPv3 implementation with which it is interoperating
the if the
VRRPv2/VRRPv3 router's advertisement rate is sub-second. VRRPv2 or VRRPv3 router's advertisement rate is sub-second.
</t> </t>
</section> </section>
<section anchor="sect-8.4.3.2"> <section anchor="sect-8.4.3.2">
<name>Overwhelming VRRPv2 Backups</name> <name>Overwhelming VRRPv2 Backups</name>
<t> <t>
It seems possible that a VRRPv3 Active Router sending at centise cond It seems possible that a VRRPv3 Active Router sending at centise cond
rates could potentially overwhelm a VRRPv2 Backup Router with rates could potentially overwhelm a VRRPv2 Backup Router with
potentially non-deterministic results. potentially non-deterministic results.
</t> </t>
<t> <t>
skipping to change at line 1931 skipping to change at line 1875
</section> </section>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
VRRP for IPvX does not currently include any type of authentication. VRRP for IPvX does not currently include any type of authentication.
Earlier versions of the VRRP specification included Earlier versions of the VRRP specification included
several types of authentication ranging from no authentication to strong several types of authentication, ranging from no authentication to stron g
authentication. authentication.
Operational experience and further analysis determined that these did Operational experience and further analysis determined that these did
not provide sufficient security to overcome the vulnerability of not provide sufficient security to overcome the vulnerability of
misconfigured secrets, causing multiple Active Routers to be elected. misconfigured secrets, causing multiple Active Routers to be elected.
Due to the nature of the VRRP protocol, even if VRRP messages are Due to the nature of the VRRP protocol, even if VRRP messages are
cryptographically protected, it does not prevent hostile nodes from cryptographically protected, it does not prevent hostile nodes from
behaving as if they are an Active Router, creating multiple behaving as if they are an Active Router, creating multiple
Active Routers. Authentication of VRRP messages could have prevented Active Routers. Authentication of VRRP messages could have prevented
a hostile node from causing all properly functioning routers from going a hostile node from causing all properly functioning routers from going
into Backup state. However, having multiple Active Routers can cause into the Backup state. However, having multiple Active Routers can caus e
as much disruption as no routers, which authentication cannot prevent. 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 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 Backup state. and create the same effect as having all routers go into the Backup stat e.
</t> </t>
<t> <t>
Some L2 switches provide the capability to filter out, for example, 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 ARP and/or ND messages from end-hosts on a switch-port basis. This
mechanism could also filter VRRP messages from switch ports mechanism could also filter VRRP messages from switch ports
associated with end-hosts and can be considered for deployments with associated with end-hosts and can be considered for deployments with
untrusted hosts. untrusted hosts.
</t> </t>
<t> <t>
It should be noted that these attacks are not worse and are a subset 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 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 of VRRP. The kind of attacks a malicious node on a LAN can perform
include: include:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
Promiscuously receiving packets for any router's MAC address. promiscuously receiving packets for any router's MAC address,
</li> </li>
<li> <li>
Sending packets with the router's MAC address as the source MAC 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 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. addressed to the router to the malicious node instead of the router,
</li> </li>
<li> <li>
Sending redirects to tell hosts to send their traffic sending redirects to tell hosts to send their traffic
somewhere else. somewhere else,
</li> </li>
<li> <li>
Sending unsolicited ND replies. sending unsolicited ND replies,
</li> </li>
<li> <li>
Answering ND requests, etc. answering ND requests, etc.
</li> </li>
</ul> </ul>
<t> <t>
All of these can be done independently of implementing VRRP. All of these can be done independently of implementing VRRP.
VRRP does not add to these vulnerabilities and most of these VRRP does not add to these vulnerabilities, and most of these
vulnerabilities are addressed independently, e.g., SEcure Neighbor Disco vulnerabilities are addressed independently, e.g., SEcure Neighbor Disco
very very (SEND)
<xref target="RFC3971"/>. <xref target="RFC3971"/>.
</t> </t>
<t> <t>
VRRP includes a mechanism VRRP includes a mechanism
(setting IPv4 TTL or IPv6 Hop Limit to 255 and checking the value on rec eipt) (setting IPv4 TTL or IPv6 Hop Limit to 255 and checking the value on rec eipt)
that protects against VRRP packets being injected from another remote that protects against VRRP packets being injected from another remote
network <xref target="RFC5082"/>. network <xref target="RFC5082"/>.
This limits most vulnerabilities to attacks on the local This limits most vulnerabilities to attacks on the local
network. network.
</t> </t>
<t> <t>
VRRP does not provide any confidentiality. Confidentiality is not VRRP does not provide any confidentiality. Confidentiality is not
necessary for the correct operation of VRRP, and there is no necessary for the correct operation of VRRP, and there is no
information in the VRRP messages that must be kept secret from other information in the VRRP messages that must be kept secret from other
nodes on the LAN. nodes on the LAN.
</t> </t>
<t> <t>
In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND) In the context of IPv6 operation, if SEND
is deployed, VRRP is compatible with the "trust anchor" and "trust is deployed, VRRP is compatible with the "trust anchor" and "trust
anchor or CGA" modes of SEND <xref target="RFC3971"/>. The SEND anchor or CGA" modes of SEND <xref target="RFC3971"/>. The SEND
configuration needs to give the Active and Backup Routers the same prefi x configuration needs to give the Active and Backup Routers the same prefi x
delegation in the certificates so that Active and Backup Routers adverti se delegation in the certificates so that Active and Backup Routers adverti se
the same set of subnet prefixes. However, the Active and Backup Routers the same set of subnet prefixes. However, the Active and Backup Routers
should have their own key pairs to avoid private key sharing. should have their own key pairs to avoid private key sharing.
</t> </t>
<t> <t>
Also in the context of IPv6 operation, it is RECOMMENDED that the Also in the context of IPv6 operation, it is <bcp14>RECOMMENDED</bcp14>
link-level security guidelines in section 2.3 of <xref target="RFC9099"/ that the
> link-level security guidelines in <xref target="RFC9099" section="2.3" s
ectionFormat="of" />
be followed. be followed.
</t> </t>
</section> </section>
<section anchor="Acknowledgments" numbered="true" toc="default">
<name>Contributors and Acknowledgments</name>
<t>
The IPv6 text in this specification is based on <xref target="RFC2338"/>
. The
authors of RFC2338 are S. Knight, D. Weaver, D. Whipple, R. Hinden,
D. Mitzel, P. Hunt, P. Higginson, M. Shand, and A. Lindem.
</t>
<t>
The author of <xref target="VRRP-IPv6"/> would also like to thank Erik N
ordmark,
Thomas Narten, Steve Deering, Radia Perlman, Danny Mitzel, Mukesh
Gupta, Don Provan, Mark Hollinger, John Cruz, and Melissa Johnson for
their helpful suggestions.
</t>
<t>
The IPv4 text in this specification is based on <xref target="RFC3768"/>
. The
authors of that specification would like to thank Glen Zorn, Michael
Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel
Halpern, Steve Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun,
Radia Perlman, Russ Housley, Harald Alvestrand, Steve Bellovin, Ned
Freed, Ted Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex
Zinin for their comments and suggestions.
</t>
<t>
Thanks to Steve Nadas for his work merging/editing <xref target="RFC3768
"/>
and <xref target="VRRP-IPv6"/> into the draft that eventually became RFC
5798
<xref target="RFC5798"/>.
</t>
<t>
Thanks to Stewart Bryant, Sasha Vainshtein, Pascal Thubert, Alexander Ok
onnikov,
Ben Niven-Jenkins, Tim Chown, Malisa Vucinic, Russ White, Donald Eastlak
e, Dave Thaler,
Eric Kline, and Vijay Gurbani for comments on the current document (RFC
5798 BIS).
Thanks to Gyan Mishra, Paul Congdon, and Jon Rosen for discussions relat
ed to the removal
of legacy technology appendices. Thanks to Dhruv Dhody and Donald Eastla
ke for
comments and suggestions for improving the IANA section. Thanks to Sasha
Vainshtein
for recommending "Maximum Advertisement Interval" validation. Thanks to
Tim Chown and
Fernando Gont for discussions and updates related to IPv6 SLAAC.
</t>
<t>
Special thanks to Quentin Armitage for a detailed review and extensive c
omments on the
current document (RFC 5798 BIS).
</t>
</section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
IANA is requested to update all IANA Registry references to <xref target IANA has updated all IANA registry references to <xref target="RFC5798"/
="RFC5798"/> >
to be references to [RFCXXXX], i.e., this document. The individual IANA to references to RFC 9568, i.e., this document. The individual IANA
references are listed below. references are listed below.
</t> </t>
<t> <t>
The value 112 is assigned to VRRP in the Assigned Internet Protocol Numb ers Registry. The value 112 is assigned to VRRP in the "Assigned Internet Protocol Num bers" registry.
</t> </t>
<t> <t>
In the "Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24 ))" of the 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" <xref target="RFC5771"/>, IANA h as assigned "IPv4 Multicast Address Space Registry" <xref target="RFC5771"/>, IANA h as assigned
the IPv4 multicast address 224.0.0.18 for VRRP. the IPv4 multicast address 224.0.0.18 for VRRP.
</t> </t>
<t> <t>
In the "Link-Local Scope Multicast Addresses" block of the "IPv6 Multica st Address In the "Link-Local Scope Multicast Addresses" registry of the "IPv6 Mult icast Address
Space Registry" <xref target="RFC3307"/>, IANA has assigned the IPv6 lin k-local Space Registry" <xref target="RFC3307"/>, IANA has assigned the IPv6 lin k-local
scope multicast address ff02:0:0:0:0:0:0:12 for VRRP for IPv6. scope multicast address ff02:0:0:0:0:0:0:12 for VRRP for IPv6.
</t> </t>
<t> <t>
In the "IANA MAC ADDRESS BLOCK" registry <xref target="I-D.ietf-intarea- rfc7042bis"/>, In the "IANA MAC ADDRESS BLOCK" registry <xref target="RFC9542"/>,
IANA has assigned blocks of Ethernet unicast addresses as IANA has assigned blocks of Ethernet unicast addresses as
follows (in hexadecimal): follows (in hexadecimal):
</t> </t>
<artwork><![CDATA[ <table anchor="table_iana_64_bit_macs">
00-01-00 to 00-01-FF VRRP <thead>
00-02-00 to 00-02-FF VRRP IPv6 <tr>
]]></artwork> <th>Addresses</th>
<th>Usage</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>00-01-00 to 00-01-FF</td>
<td>VRRP (Virtual Router Redundancy Protocol)</td>
<td>RFC 9568</td>
</tr>
<tr>
<td>00-02-00 to 00-02-FF</td>
<td>VRRP IPv6 (Virtual Router Redundancy Protocol
IPv6)</td>
<td>RFC 9568</td>
</tr>
</tbody>
</table>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-vrrp-ipv6-spec" to="VRRP-IPv6"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119. <references>
xml"/> <name>References</name>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3307. <references>
xml"/> <name>Normative References</name>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4291. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/> xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4443. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3307.
xml"/> xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4861. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.
xml"/> xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5082. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.
xml"/> xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5771. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.
xml"/> xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5082.
xml"/> xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8200. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5771.
xml"/> xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.
-intarea-rfc7042bis.xml"/> xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9542.
xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="VRRP-IPv6">
<front> <!-- [VRRP-IPv6] draft-ietf-vrrp-ipv6-spec-08 IESG state: Expired (IESG
: Dead)
Long way used to fix Bob Hinden's initials-->
<reference anchor="I-D.ietf-vrrp-ipv6-spec" target="https://datatracker.ietf.org
/doc/html/draft-ietf-vrrp-ipv6-spec-08">
<front>
<title>Virtual Router Redundancy Protocol for IPv6</title> <title>Virtual Router Redundancy Protocol for IPv6</title>
<author initials="R." surname="Hinden" fullname="R. Hinden"> <author fullname="Robert Hinden" initials="R." surname="Hinden">
<organization>Nokia</organization>
</author> </author>
<author initials="J." surname="Cruz" fullname="J. Cruz"> <author fullname="John Cruz" initials="J." surname="Cruz">
<organization>Cisco Systems</organization>
</author> </author>
<date month="March" year="2007"/> <date day="5" month="March" year="2007"/>
</front> </front>
<seriesInfo name="Work" value="in Progress"/> <seriesInfo name="Internet-Draft" value="draft-ietf-vrrp-ipv6-spec-08"/>
</reference> </reference>
<reference anchor="IPSTB">
<reference anchor="IPSTB">
<front> <front>
<title>Development of Router Clusters to Provide Fast Failover in IP Network <title>Development of Router Clusters to Provide Fast Failover in IP Network
s", s
Digital Technical Journal, Volume 9 Number 3
</title> </title>
<author> <author initials="P" surname="Higginson" fullname="Peter L. Higginson">
<organization>Higginson, P. and M. Shand</organization> <organization/>
</author>
<author initials="M" surname="Shand" fullname="Michael C. Shand">
<organization/>
</author> </author>
<date year="1997"/> <date year="1997"/>
</front> </front>
<refcontent>Digital Technical Journal, Volume 9, Number 3</refcontent>
</reference> </reference>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1071.xml"
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1071.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2328.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1256.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1256.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2131.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2281.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2281.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2338.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2338.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2453.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2453.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3768.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3768.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3971.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4311.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4311.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4862.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5798.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5798.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7217.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8064.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8064.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8981.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9099.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9099.xml"
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9131.xml" />
/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9131.xml"
<reference anchor="NISTIR8366" target="https://doi.org/10.6028/NIST.IR.8366"> />
<reference anchor="NISTIR8366">
<front> <front>
<title>Guidance for NIST Staff on Using Inclusive Language in Documentary St andards, <title>Guidance for NIST Staff on Using Inclusive Language in Documentary St andards,
National Institute of Standards and Technology (NIST) Interagency or Internal Re </title>
port 8366</title> <author>
<author surname="NIST"/> <organization>National Institute of Standards and Technology (NIST)</organizat
ion>
</author>
<date year="2021" month="April"/> <date year="2021" month="April"/>
</front> </front>
<seriesInfo name="NISTIR" value="8366"/> <seriesInfo name="NISTIR" value="8366"/>
<seriesInfo name="DOI" value="10.6028/NIST.IR.8366"/>
</reference> </reference>
</references> </references>
</references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The IPv6 text in this specification is based on <xref target="RFC2338"/>
. The
authors of <xref target="RFC2338"/> are <contact fullname="S. Knight"/>,
<contact fullname="D. Weaver"/>, <contact fullname="D. Whipple"/>, <contact ful
lname="R. Hinden"/>,
<contact fullname="D. Mitzel"/>, <contact fullname="P. Hunt"/>, <contact
fullname="P. Higginson"/>, <contact fullname="M. Shand"/>, and <contact fullnam
e="A. Lindem"/>.
</t>
<t>
The authors of <xref target="I-D.ietf-vrrp-ipv6-spec"/> would also like
to thank <contact fullname="Erik Nordmark"/>,
<contact fullname="Thomas Narten"/>, <contact fullname="Steve Deering"/>
, <contact fullname="Radia Perlman"/>, <contact fullname="Danny Mitzel"/>, <cont
act fullname="Mukesh
Gupta"/>, <contact fullname="Don Provan"/>, <contact fullname="Mark Holl
inger"/>, <contact fullname="John Cruz"/>, and <contact fullname="Melissa Johnso
n"/> for
their helpful suggestions.
</t>
<t>
The IPv4 text in this specification is based on <xref target="RFC3768"/>
. The
authors of that specification would like to thank <contact fullname="Gle
n Zorn"/>, <contact fullname="Michael
Lane"/>, <contact fullname="Clark Bremer"/>, <contact fullname="Hal Pete
rson"/>, <contact fullname="Tony Li"/>, <contact fullname="Barbara Denny"/>, <co
ntact fullname="Joel
Halpern"/>, <contact fullname="Steve M. Bellovin"/>, <contact fullname="
Thomas Narten"/>, <contact fullname="Rob Montgomery"/>, <contact fullname="Rob C
oltun"/>,
<contact fullname="Radia Perlman"/>, <contact fullname="Russ Housley"/>,
<contact fullname="Harald Alvestrand"/>, <contact fullname="Ned
Freed"/>, <contact fullname="Ted Hardie"/>, <contact fullname="Bert Wijn
en"/>, <contact fullname="Bill Fenner"/>, and <contact fullname="Alex
Zinin"/> for their comments and suggestions.
</t>
<t>
Thanks to <contact fullname="Steve Nadas"/> for his work merging/editing
<xref target="RFC3768"/>
and <xref target="I-D.ietf-vrrp-ipv6-spec"/> into the document that even
tually became
<xref target="RFC5798"/>.
</t>
<t>
Thanks to <contact fullname="Stewart Bryant"/>, <contact fullname="Sasha
Vainshtein"/>, <contact fullname="Pascal Thubert"/>, <contact fullname="Alexand
er Okonnikov"/>,
<contact fullname="Ben Niven-Jenkins"/>, <contact fullname="Tim Chown"/>
, <contact fullname="Mališa Vučinić"/>, <contact fullname="Russ White"/>, <conta
ct fullname="Donald Eastlake"/>, <contact fullname="Dave Thaler"/>,
<contact fullname="Eric Kline"/>, and <contact fullname="Vijay Gurbani"/
> for comments on the current document (RFC 9568).
Thanks to <contact fullname="Gyan Mishra"/>, <contact fullname="Paul Con
gdon"/>, and <contact fullname="Jon Rosen"/> for discussions related to the remo
val
of legacy technology appendices. Thanks to <contact fullname="Dhruv Dhod
y"/> and <contact fullname="Donald Eastlake"/> for
comments and suggestions for improving the IANA section. Thanks to <cont
act fullname="Sasha Vainshtein"/>
for recommending "Maximum Advertisement Interval" validation. Thanks to
<contact fullname="Tim Chown"/> and
<contact fullname="Fernando Gont"/> for discussions and updates related
to IPv6 SLAAC.
</t>
<t>
Special thanks to <contact fullname="Quentin Armitage"/> for a detailed
review and extensive comments on the
current document (RFC 9568).
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 199 change blocks. 
692 lines changed or deleted 715 lines changed or added

This html diff was produced by rfcdiff 1.48.