<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. --> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. --> rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>
<rfc
    xmlns:xi="http://www.w3.org/2001/XInclude"
    category="std"
    docName="draft-ietf-rtgwg-vrrp-rfc5798bis-18"
    ipr="trust200902"
    number="9568"
    obsoletes="5798"
    updates=""
    submissionType="IETF"
    xml:lang="en"
    tocInclude="true"
    tocDepth="4"
    symRefs="true"
    sortRefs="true"
    consensus="true"
    version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- category values: std, bcp, info, exp, and historic
       ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
       you can add the attributes updates="NNNN" and obsoletes="NNNN"
       they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <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) Version 3 for IPv4 and IPv6</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-vrrp-rfc5798bis.xml"/>

    <!-- Another author who claims to be an editor --> name="RFC" value="9568"/>
    <author initials="A" surname="Lindem" fullname="Acee Lindem">
      <organization>LabN Consulting, L.L.C.</organization>
      <address>
	<postal>
	  <street>301 Midenhall Way</street>
	  <city>Cary</city>
	  <region>NC</region>
	  <code>27513</code>
	  <country>USA</country>
	  <country>United States of America</country>
	</postal>
	<email>acee.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="A" surname="Dogra" fullname="Aditya Dogra">
      <organization>Cisco Systems</organization>
      <address>
	<postal>
	  <street>Sarjapur Outer Ring Road</street>
	  <city>Bangalore</city>
	  <region>Karnataka</region>
	  <code>560103</code>
	  <country>India</country>
	</postal>
	<email>addogra@cisco.com</email>
      </address>
    </author>
    <date/>
    <area>General</area>
    <keyword>RFC</keyword>
    <date month="April" year="2024"/>
    <area>Routing Area</area>
    <keyword>VRRP</keyword>

    <abstract>
      <t>
        This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP)
        for IPv4 and IPv6. It obsoletes RFC 5798 5798, which previously specified VRRP (version 3).
        RFC 5798 obsoleted RFC 3768 3768, which specified VRRP (version 2) for IPv4.
        VRRP specifies an election protocol that dynamically assigns responsibility for a
        Virtual Router to one of the VRRP Routers on a LAN.  The VRRP Router
        controlling the IPv4 or IPv6 address(es) associated with a Virtual
        Router is called the Active Router, and it forwards packets routed to these
        IPv4 or IPv6 addresses.  Active Routers are configured with
        virtual IPv4 or IPv6 addresses, and Backup Routers infer the
        address family of the virtual addresses being advertised based on the
        IP protocol version.  Within a VRRP Router, the Virtual Routers in
        each of the IPv4 and IPv6 address families are independent of one another
        and always treated as separate Virtual Router instances.
        The election process provides dynamic
        failover in the forwarding responsibility should the Active Router become
        unavailable.  For IPv4, the advantage gained from using VRRP is a
        higher-availability default path without requiring configuration of
        dynamic routing or router discovery protocols on every end-host.  For
        IPv6, the advantage gained from using VRRP for IPv6 is a quicker
        switchover to Backup Routers than can be obtained with standard IPv6
        Neighbor Discovery mechanisms.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1">
      <name>Introduction</name>
      <t>
        This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP)
        for IPv4 and IPv6. It obsoletes RFC 5798 <xref target="RFC5798"/> target="RFC5798"/>, which previously
        specified VRRP (version 3). RFC 5798 <xref target="RFC5798"/> obsoleted RFC 3768 <xref target="RFC3768"/> target="RFC3768"/>,
        which specified VRRP (version 2) for IPv4.
        VRRP specifies an election protocol that dynamically
        assigns responsibility for a Virtual Router
        (refer to <xref target="sect-1.7"/>) to one of the VRRP
        routers
        Routers on a LAN.  The VRRP Router controlling the IPv4 or IPv6
        address(es) associated with a Virtual Router is called the Active Router,
        and it forwards packets routed to these IPv4 or IPv6 addresses (except for
        packets addressed to these addresses as decribed described in <xref target="sect-8.3.1"/>).
        VRRP Active Routers are configured with virtual IPv4 or IPv6 addresses,
        and Backup Routers infer the address family of the virtual
        addresses being advertised based on the IP protocol version.  Within a
        VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address
        families are independent of one another
        and always treated as separate Virtual Router instances. The
        election process provides dynamic failover in the forwarding
        responsibility should the Active Router become unavailable.
      </t>
      <t>
        VRRP provides a function similar to the proprietary protocols "Hot Hot Standby Router Protocol (HSRP)" (HSRP)
        <xref target="RFC2281"/> and "IP IP Standby Protocol" Protocol <xref target="IPSTB"/>.
      </t>
      <section anchor="sect-1.1">
        <name>RFC 5798 Differences</name>
        <name>Differences from RFC 5798</name>
        <t>
          The following changes have been made from RFC 5798: <xref target="RFC5798"/>:
        </t>
        <ol spacing="normal" type="1">
          <li>
	    The VRRP terminology has been updated to conform to inclusive language
            guidelines for IETF technologies.
            The IETF has designated the National Institute of Standards and Technology (NIST)
            document "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards"
            <xref target="NISTIR8366"/> for its inclusive language guidelines.
          </li>
          <li>
            The term for the VRRP Router assuming forwarding responsibility has been changed
            to "Active Router" to be consistent with IETF inclusive terminology. Additionally,
            inconsistencies in RFC 5798 the terminology of <xref target="RFC5798"/> for both "Active Router" and "Backup Router"
            were corrected. Additionally, the undesirable term for attracting and dropping
            unreachable packets has been changed.
          </li>
          <li>
            Errata pertaining to the state machines in <xref target="state-machine"/> were
            corrected.
          </li>
          <li>
            The checksum calculation in <xref target="sect-5.2.8"/> has been clarified to specify
            precisely what is included and that it does not include the pseudo-header for IPv4.
          </li>
          <li>
            When a VRRP advertisement is received from a lower priority VRRP router, Router, the Active
            VRRP router Router will immediately send a VRRP advertisement to assure learning bridges
            will bridge the packets to the correct Ethernet segment
            (refer to <xref target="sect-6.4.3"/>).
          </li>
          <li>
            Appendices describing operation over legacy technologies (FDDI, (Fiber Distributed Data Interface (FDDI), Token
            Ring, and ATM LAN Emulation) were removed.
          </li>
          <li>
            A recommendation was added indicating that IPv6 Unsolicited Neighbor Advertisements
            SHOULD
            <bcp14>SHOULD</bcp14> be accepted by the Active and Backup Routers <xref target="sect-8.2.4"/>. (<xref target="sect-8.2.4"/>).
          </li>
          <li>
            Checking that the Maximum Advertisement Intervals match is recommended recommended, although this will
            not result in the VRRP packet being dropped <xref target="sect-7.1"/>. (<xref target="sect-7.1"/>).
          </li>
          <li>
            Miscellaneous editorial changes were made for readability.
          </li>
          <li>
            The IANA Considerations section was augmented to include all the IPv4/IPv6
            multicast address allocations and Ethernet MAC Media Access Control (MAC) address allocations.
          </li>
        </ol>
      </section>
      <section anchor="sect-1.2">
        <name>A Note on Terminology</name>
        <t>
	  This document discusses both IPv4 and IPv6 operations, and with
          respect to the VRRP protocol, many of the descriptions and procedures
          are common.  In this document, it would be less verbose to be able to
          refer to "IP" to mean either "IPv4 or IPv6".  However, historically,
          the term "IP" often refers to IPv4.  For this reason, in this
          specification, the term "IPvX" (where X is 4 or 6) is introduced to
          mean either "IPv4" or "IPv6".  In this text, where the IP version
          matters, the appropriate term is used, and the use of the term "IP" is
          avoided.
        </t>
      </section>
      <section anchor="sect-1.3">
        <name>IPv4</name>
        <t>
	  There are a number of methods that an IPv4 end-host can use to
          determine its first-hop router for a particular IPv4 destination.

          These include running (or snooping) a dynamic routing protocol such
          as Routing Information Protocol (RIP) <xref target="RFC2453"/> or OSPF version 2
	  <xref target="RFC2328"/>, running an ICMP router discovery client
          <xref target="RFC1256"/>, running DHCPv4 <xref target="RFC2131"/>, or using a
          statically configured default route.
        </t>
        <t>
	  Running a dynamic routing protocol on every end-host may
          not be feasible for a number of reasons, including administrative
          overhead, processing overhead, security issues, or the lack of an
          implementation for a particular platform.  Neighbor or router discovery
          protocols may require active participation by all hosts on a network,
          requiring large timer values to reduce protocol overhead associated
          with the protocol packet processing for each host.  This can result in
          a significant delay in the detection of an unreachable router and, router, and
          such a delay may introduce unacceptably long periods of unreachability for the
          default route.
        </t>
        <t>
	  The use of a manually configured default route (either via a static route
          or DHCPv4) is quite popular since it minimizes configuration and
          processing overhead on the end-host and
          is supported by virtually every IPv4 implementation.
          However, this creates a single point of failure.  Loss of the default
          router results in a catastrophic event, isolating all end-hosts that
          are unable to detect an available alternate path.
        </t>
        <t>
	  The Virtual Router Redundancy Protocol (VRRP) is designed to
          eliminate the single point of failure inherent in a network utilizing
          default routing.  VRRP specifies an election protocol that
          dynamically assigns responsibility for a Virtual Router to one of the
          VRRP Routers on a LAN.  The VRRP Router controlling the IPv4
          address(es) associated with a Virtual Router is called the Active Router and
          forwards packets sent to these IPv4 addresses.  The election process
          provides dynamic failover of the forwarding responsibility should the
          Active Router become unavailable.  Any of the Virtual Router's IPv4
          addresses on a LAN can then be used as the default first hop first-hop
	  router by end-hosts.  The advantage gained from using VRRP is a
          higher availability default path without requiring configuration of
          dynamic routing or a router discovery protocol on every end-host.
        </t>
      </section>
      <section anchor="sect-1.4">
        <name>IPv6</name>
        <t>
	  IPv6 hosts on a LAN will usually learn about one or more default
          routers by receiving Router Advertisements sent using the IPv6
          Neighbor Discovery (ND) protocol <xref target="RFC4861"/>.
          The Router Advertisements are periodically multicast
          at a rate such that the hosts can take more
          than 10 seconds to learn the default routers on a LAN.
          They are not sent frequently enough to rely on the absence
          of the Router Advertisement to detect router failures.
        </t>
        <t>
	  The ND protocol includes a mechanism called Neighbor
          Unreachability Detection to detect the failure of a neighbor node
          (router or host) or the forwarding path to a neighbor.  This is done
          by sending unicast ND Neighbor Solicitation messages to the neighbor
          node.  To reduce the overhead of sending Neighbor Solicitations, they
          are only sent to neighbors to which the node is actively sending
          traffic and only after there has been no positive indication that the
          router is up for a period of time.  Using the default parameters in
          ND, it can take a host more than 10 seconds to learn that a router is
          unreachable before it will switch to another default router.  This
          delay would be very noticeable to users and cause some transport
          protocol implementations to time out.
        </t>

        <t>
	  While the ND unreachability detection Neighbor Unreachability Detection could be made quicker by
          configuring the timer intervals to be more aggressive (note that the current
          lower limit for this is 5 seconds), this would have the downside of
          significantly increasing the overhead of ND traffic, especially when
          there are many hosts all trying to determine the reachability of one
          or more routers.
        </t>
        <t>
	  The Virtual Router Redundancy Protocol for IPv6 provides a much
          faster switchover to an alternate default router than can be obtained
          using standard ND procedures.  Using VRRP, a Backup Router can take
          over for a failed default router in around three seconds (using VRRP
          default parameters).  This is done without any interaction with the
          hosts and a minimum amount of VRRP traffic.
        </t>
      </section>
      <section anchor="sect-1.5">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
          NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
          "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
      <section anchor="sect-1.6">
        <name>Scope</name>
        <t>
	  The remainder of this document describes the features, design goals,
          and theory of operation of VRRP.  The message formats, protocol
          processing rules, and state machine that guarantee convergence to a
          single Active Router are presented.  Finally, operational
          issues related to MAC address mapping, handling of ARP messages,
          generation of ICMP redirect messages, and security issues are
          addressed.
        </t>
      </section>
      <section anchor="sect-1.7">
        <name>Definitions</name>
        <dl newline="false" spacing="normal" indent="24">
	  <dt>VRRP Router</dt>
	  <dd>
	    <t>
	      A router running the Virtual Router
	      Redundancy Protocol.  It may participate as
              one or more Virtual Routers.
	    </t>
	  </dd>
	  <dt>Virtual Router</dt>
	  <dd>
	    <t>
	      An abstract object managed by VRRP that acts
	      as a default router for hosts on a shared
              LAN.  It consists of a Virtual Router
              Identifier and either a set of associated
              IPv4 addresses or a set of associated IPv6
              addresses across a common LAN.  A VRRP Router
              can serve as a Backup Router for one or more
              Virtual Routers.
	    </t>
	  </dd>
	  <dt>Virtual Router Identifier</dt>
	  <dd>
	    <t>
              An integer value (1-255) identifying an instance
              of a Virtual Router on a LAN. Also referred by its
              acronym, VRID.
	    </t>
	  </dd>
	  <dt>Virtual Router MAC Address</dt>
	  <dd>
	    <t>
              The multicast Ethernet MAC address used for
              VRRP advertisements for a VRID. Refer to
              <xref target="sect-7.3"/>.
	    </t>
	  </dd>
	  <dt>IP Address Owner</dt>
	  <dd>
	    <t>
	      The VRRP Router that has the Virtual Router's
	      IPvX address(es) as real interface
              address(es).  This is the router that, when
              up, will respond to packets addressed to one
              of these IPvX addresses for ICMP pings, TCP
              connection requests, etc.
	    </t>
	  </dd>
	  <dt>Primary IP Address</dt>
	  <dd>
	    <t>
	      In IPv4, an IPv4 address selected from the
	      set of real interface addresses.  One
              possible selection algorithm is to always
              select the first address.  In IPv4, VRRP
              advertisements are always sent using the
              primary IPv4 address as the source of the
              IPv4 packet.  In IPv6, the link-local address
              of the interface over which the packet is
              transmitted is used.
	    </t>
	  </dd>
	  <dt>Forwarding Responsibility</dt>
	  <dd>
	    <t>
	      The responsibility for forwarding packets sent to
              the IPvX address(es) associated with the
              Virtual Router. This includes receiving packets
              sent to the Virtual Router MAC Address, address, forwarding these
              packets based on the local RIB (Routing Routing Information Base)/FIB
              (Forwarding Base (RIB) /
              Forwarding Information Base), Base (FIB), answering
              ARP requests for the IPv4 address(es), and answering ND
              requests for the IPv6 address(es).
	    </t>
	  </dd>
	  <dt>Active Router</dt>
	  <dd>
	    <t>
	      The VRRP Router that is assuming the
	      responsibility of forwarding packets sent to
              the IPvX address(es) associated with the
              Virtual Router, answering ARP requests
	      for the IPv4 address(es), and answering ND
              requests for the IPv6 address(es).  Note that
              if the IPvX address owner is available, then
              it will always be the Active Router.
	    </t>
	  </dd>
	  <dt>Backup Router(s)</dt>
	  <dd>
	    <t>
	      The set of VRRP Routers available to assume
	      forwarding responsibility for a Virtual
              Router should the current Active Router fail.
	    </t>
	  </dd>
	  <dt>Drop Route</dt>
	  <dd>
	    <t>
	      A route installed in the RIB (Routing Routing Information Base) Base (RIB) that
              will result in traffic with a destination address that matches
              the route to be dropped.
	    </t>
	  </dd>
        </dl>
      </section>
    </section>
    <section anchor="sect-2">
      <name>Required Features</name>
      <t>
	This section describes the set of features that were considered
        mandatory and that guided the design of VRRP.
      </t>
      <section anchor="sect-2.1">
	<name>IPvX Address Backup</name>
	<t>
	  Backup of an IPvX address or addresses is the primary function of
          VRRP.  When providing election of an Active Router and the
          additional functionality described below; below, the protocol should
        strive to:</t>
	<ul spacing="normal">
	  <li>Minimize
	  <li>minimize the duration of unreachability.</li>
	  <li>Minimize unreachability,</li>
	  <li>minimize the steady-state bandwidth overhead and processing
          complexity.</li>
	  <li>Function
          complexity,</li>
	  <li>function over a wide variety of multiaccess LAN technologies
          capable of supporting IPvX traffic.</li>
	  <li>Allow traffic,</li>
	  <li>allow multiple Virtual Routers on a network for load-balancing.</li>
	  <li>Support load-balancing, and</li>
	  <li>support multiple logical IPvX subnets on a single LAN segment.</li>
	</ul>
      </section>
      <section anchor="sect-2.2">
	<name>Preferred Path Indication</name>
	<t>
	  A simple model of Active Router election among a set of redundant routers is
          to treat each router with equal preference and claim victory after
          converging to any router as the Active Router.  However, there are likely to be
          many environments where there is a distinct preference (or range of
          preferences) among the set of redundant routers.  For example, this
          preference may be based upon access link cost or speed, router
          performance or reliability, or other policy considerations.  The
          protocol should allow the expression of this relative path preference
          in an intuitive manner and guarantee Active Router convergence to the most
          preferred Virtual Router currently available.
        </t>
      </section>
      <section anchor="sect-2.3">
	<name>Minimization of Unnecessary Service Disruptions</name>
	<t>
	  Once Active Router election has been performed, any unnecessary transition
          between Active and Backup Routers can result in a disruption in of
          service.  The protocol should ensure that, after Active Router election, no
          state transition is triggered by any Backup Router of equal or lower
          preference as long as the Active Router continues to function properly.
        </t>
	<t>
	  Some environments may find it beneficial to avoid the state
          transition triggered when a router that is preferred over the current
          Active Router becomes available.  It may be useful to support an override of
          the immediate restoration to the preferred path.
        </t>
      </section>
      <section anchor="sect-2.4">
	<name>Efficient Operation over Extended LANs</name>
	<t>
	  Sending IPvX packets, i.e., sending either IPv4 or IPv6, on a
          multiaccess LAN requires mapping from an IPvX address to a MAC
          address.  The use of the Virtual Router MAC address in an extended
          LAN employing learning bridges can have a significant effect on the
          bandwidth overhead of packets sent to the Virtual Router.  If the
          Virtual Router MAC address is never used as the source address in a
          link-level frame, then the MAC address location is never learned,
          resulting in flooding of all packets sent to the Virtual Router.  To
          improve the efficiency in this environment, the protocol should do the
          following:
        </t>
        <ol spacing="normal" type="1">
          <li>
            Use the Virtual Router MAC address as the source in a packet sent
            by the Active Router to trigger MAC learning.
          </li>
          <li>
            Trigger a message immediately after transitioning to the
            Active Router to update MAC learning.
          </li>
          <li>
            Trigger periodic messages from the Active Router to
            maintain the MAC address cache.
          </li>
        </ol>
      </section>
      <section anchor="sect-2.5">
	<name>Sub-Second
	<name>Sub-second Operation for IPv4 and IPv6</name>
	<t>
	  Sub-second detection of Active Router failure is needed in both
          IPv4 and IPv6 environments.  Earlier work proposed that sub-second
          operation was for IPv6 IPv6, and this specification leverages that earlier
          approach for both IPv4 and IPv6.
        </t>
	<t>
	  One possible problematic scenario that may occur when using a small
          Advertisement_Interval (refer to <xref target="sect-6.1"/>) is
          when a VRRP Router is generating more packets than it can transmit, and a queue
          builds up on the VRRP Router.  When this occurs, it is possible that packets being
          transmitted onto the VRRP-protected LAN could see a larger queueing
          delay than the smallest Advertisement_Interval.  In this case,
          the Active_Down_Interval (refer to <xref target="sect-6.1"/>) may be small
          enough that normal queuing
          delays might cause a Backup Router to conclude that the Active Router is down, down
          and, hence, promote itself to Active Router.  Very shortly afterwards, the
          delayed VRRP packets from the original Active Router cause a the VRRP Router to switch back to Backup
          Router.  Furthermore, this process can repeat many times per second,
          causing a significant disruption of traffic.  To mitigate this problem,
          giving VRRP packets priority on egress interface queues should be considered.
          If the Active Router observes that this is occurring, it SHOULD <bcp14>SHOULD</bcp14> log the problem
          (subject to rate-limiting).
        </t>
      </section>
    </section>
    <section anchor="sect-3">
      <name>VRRP Overview</name>
      <t>
	VRRP specifies an election protocol to provide the Virtual Router
        function described earlier.  All protocol messaging is performed
        using either IPv4 or IPv6 multicast datagrams. Thus, the protocol can
        operate over a variety of multiaccess LAN technologies supporting
        IPvX multicast.  Each link of a VRRP Virtual Router has a single
        well-known MAC address allocated to it.  This document currently only
        details the mapping to networks using an IEEE 802 48-bit MAC
        address.  The Virtual Router MAC address is used as the source in all
        periodic VRRP messages sent by the Active Router to enable MAC
      learning by layer-2 Layer 2 (L2) bridges on an extended LAN.</t>
      <t>
	A Virtual Router is defined by its Virtual Router Identifier (VRID)
        and a set of either IPv4 or IPv6 address(es).  A VRRP Router may
        associate a Virtual Router with its real address on an interface.
        The scope of each Virtual Router is restricted to a single LAN.  A
        VRRP Router may be configured with additional Virtual Router mappings
        and priority for Virtual Routers it is willing to back up.  The
        mapping between the VRID and its IPvX address(es) must be coordinated
        among all VRRP Routers on a LAN.
      </t>
      <t>
	There is no restriction against reusing a VRID with a different
        address mapping on different LANs, nor is there a restriction against
        using the same VRID number for a set of IPv4 addresses and a set of
        IPv6 addresses. However, these are two different Virtual Routers.
      </t>
      <t>
	To minimize network traffic, only the Active Router for each Virtual Router
        sends periodic VRRP Advertisement messages.  A Backup Router will not
        attempt to preempt the Active Router unless the Backup Router
        has a higher priority.  This
        eliminates service disruption unless a more preferred path becomes
        available.  It's also possible to administratively prohibit Active Router
        preemption attempts.  The only exception is that a VRRP Router will
        always become the Active Router for any Virtual Router associated with
        address(es) it owns.  If the Active Router becomes unavailable, then the
        highest-priority Backup Router will transition to the Active Router
        after a short delay, providing a controlled transition of Virtual Router
        responsibility with minimal service interruption.
      </t>
      <t>
	The VRRP protocol design provides rapid transition from the Backup Router to
        the Active Router to minimize service interruption and incorporates
        optimizations that reduce protocol complexity while guaranteeing
        controlled Active Router transition for typical operational scenarios.  These
        optimizations result in an election protocol with minimal runtime
        state requirements, minimal active protocol states, and a single
        message type and sender.  The typical operational scenarios are
        defined to be two redundant routers and/or distinct path preferences
        for each router.  A side effect when these assumptions are violated,
        i.e., more than two redundant paths with equal preference, is
        that duplicate packets may be forwarded for a brief period during
        Active Router election.  However, the typical scenario assumptions are
        likely to cover the vast majority of deployments, loss of the Active
        Router is infrequent, and the expected duration for Active Router election
        convergence is quite small (&lt; 4 seconds when using the default
        Advertisement_Interval and configurable to &lt; 1/25 second).  Thus,
        the VRRP optimizations represent significant simplifications in
        the protocol design while incurring an insignificant probability of
        brief network disruption.
      </t>
    </section>
    <section anchor="sect-4">
      <name>Sample Configurations</name> VRRP Networks</name>
      <section anchor="sect-4.1">
	<name>Sample Configuration VRRP Network 1</name>
	<t>
	  The following figure shows a simple network with two VRRP Routers
          implementing one Virtual Router.
        </t>
 	<figure>
 	  <name>Sample VRRP Network 1</name>
        <artwork><![CDATA[
        +-----------+ +-----------+
        | Router-1  | | Router-2  |
        |(AR VRID=1)| |(BR VRID=1)|
        |           | |           |
VRID=1  +-----------+ +-----------+
IPvX A------>*            *<---------IPvX B
             |            |
             |            |
-------------+------------+--+-----------+-----------+-----------+
                             ^           ^           ^           ^
                             |           |           |           |
     Default Router          |           |           |           |
     IPvX addresses Addresses ---> (IPvX A)    (IPvX A)    (IPvX A)    (IPvX A)
                             |           |           |           |
                    IPvX H1->*  IPvX H2->*  IPvX H3->*  IPvX H4->*
                          +--+--+     +--+--+     +--+--+     +--+--+
                          |  H1 |     |  H2 |     |  H3 |     |  H4 |
                          +-----+     +-----+     +--+--+     +--+--+
Legend:
      --+---+---+-- = Ethernet
                  H = Host computer
                 AR = Active Router
                 BR = Backup Router
                 *  =  IPvX Address: X is 4 everywhere in IPv4 case
                                     X is 6 everywhere in IPv6 case
                 (IPvX) = Default Router for hosts
                 ]]></artwork>
	</figure>
        <t>
          In the IPv4 case, i.e., IPvX is IPv4 everywhere in the figure,
          each router is permanently assigned an IPv4 address on the LAN
          interface (Router-1 is assigned IPv4 A and Router-2 is assigned IPv4 B), and
          each host installs a default route (learned through DHCPv4 or via a
          configured static route) through one of the routers
          (in this example, they all use Router-1's IPv4 A).
        </t>
        <t>
          In the IPv6 case, i.e., IPvX is IPv6 everywhere in the figure, each router has its own
          Link-Local
          link-local IPv6 address on the LAN interface, interface and a link-local
          IPv6 address per VRID that is shared with the other routers that serve the same VRID.
          Each host learns a default route from Router
          Advertisements through one of the routers (in this example, they all
          use Router-1's IPv6 Link-Local A).
        </t>
        <t>
          In an IPv4 VRRP environment, each router supports reception and transmission for
          the exact same IPv4 address.  Router-1 is said to be the IPv4
          address owner of IPv4 A, and Router-2 is the IPv4 address owner of
          IPv4 B.  A Virtual Router is then defined by associating a unique
          identifier (the VRID) with the address owned by Router-1.
        </t>
        <t>
          In an IPv6 VRRP environment, each router will support transmission and
          reception for the IPv6 addresses associated with the VRID.
          Router-1 is said to be the IPv6 address owner
          of IPv6 A, and Router-2 is the IPv6 address owner of IPv6 B.  A Virtual
          Router is then defined by associating a unique identifier (the
          VRID) with the address owned by Router-1.
        </t>
        <t>
          Finally, in both the IPv4 and IPv6 cases, the VRRP protocol manages
          Virtual Router failover to a Backup Router.
        </t>
        <t>
          The IPvX example above shows a Virtual Router configured to cover the
          IPvX address owned by Router-1 (VRID=1, IPvX_Address=A).  When VRRP is
          enabled on Router-1 for VRID=1, it will assert itself as the Active Router, with
          priority = 255, since it is the IPvX address owner for the Virtual
          Router IPvX address.  When VRRP is enabled on Router-2 for VRID=1, it will
          transition to the Backup Router, with priority = 100 (the default priority is
          100), since it is not the IPvX address owner.  If Router-1 should fail,
          then the VRRP protocol will transition Router-2 to the Active Router, temporarily
          taking over forwarding responsibility for IPvX A to provide
          uninterrupted service to the hosts.
        </t>
        <t>
          Note that in both cases in this example, IPvX B is not backed up and it
          is only used by Router-2 as its interface address.  In order to back up
          IPvX B, a second Virtual Router must be configured.  This is shown in
          the next section.
        </t>
      </section>
      <section anchor="sect-4.2">
        <name>Sample Configuration VRRP Network 2</name>
        <t>
          The following figure shows a configuration with two Virtual Routers
          with the hosts splitting their traffic between them.
        </t>
 	<figure>
 	  <name>Sample VRRP Network 2</name>
        <artwork><![CDATA[
        +-----------+  +-----------+
        |  Router-1 |  | Router-2  |
        |(AR VRID=1)|  |(BR VRID=1)|
        |(BR VRID=2)|  |(AR VRID=2)|
VRID=1  +-----------+  +-----------+  VRID=2
IPvX A ----->*             *<---------- IPvX B
             |             |
             |             |
   ----------+-------------+-+-----------+-----------+-----------+
                             ^           ^           ^           ^
                             |           |           |           |
     Default Router          |           |           |           |
     IPvX addresses Addresses ---> (IPvX A)    (IPvX A)    (IPvX B)    (IPvX B)
                             |           |           |           |
                    IPvX H1->*  IPvX H2->*  IPvX H3->*  IPvX H4->*
                          +--+--+     +--+--+     +--+--+     +--+--+
                          |  H1 |     |  H2 |     |  H3 |     |  H4 |
                          +-----+     +-----+     +--+--+     +--+--+

 Legend:
      ---+---+---+--  =  Ethernet
                   H  =  Host computer
                  AR  =  Active Router
                  BR  =  Backup Router
                   *  =  IPvX Address: X is 4 everywhere in IPv4 case
                                       X is 6 everywhere in IPv6 case
              (IPvX)  =  Default Router for hosts
              ]]></artwork>
	</figure>
        <t>
          In the IPv4 example above, i.e., IPvX is IPv4 everywhere in the
          figure, half of the hosts have configured a static default route through
          Router-1's IPv4 A, and half are using Router-2's IPv4 B.  The configuration
          of Virtual Router VRID=1 is exactly the same as in the first example
          (see <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
          this case, Router-2 will assert itself as the Active Router for VRID=2 VRID=2, while Router-1
          will act as a Backup Router.  This scenario demonstrates a deployment
          providing load-splitting when both routers are available, while
          providing full redundancy for robustness.
        </t>
        <t>
          In the IPv6 example above, i.e., IPvX is IPv6 everywhere in the
          figure, half of the hosts are using a default route through
          Router-1's IPv6 A, and half are using Router-2's IPv6 B.  The configuration
          of Virtual Router VRID=1 is exactly the same as in the first example
          (see <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
          this case, Router-2 will assert itself as the Active Router for VRID=2 VRID=2, while Router-1
          will act as a Backup Router.  This scenario demonstrates a deployment
          providing load-splitting when both routers are available, available while
          providing full redundancy for robustness.
        </t>
        <t>
          Note that the details of load-balancing are out of scope of this
          document.  However, in a case where the servers need different
          weights, it may not make sense to rely on router advertisements Router Advertisements alone
          to balance the host traffic between the routers <xref target="RFC4311"/>.
        </t>
      </section>
    </section>
    <section anchor="sect-5">
      <name>Protocol</name>
      <t>
        The purpose of the VRRP Advertisement is to communicate to all VRRP Routers
        the priority, Max Maximum Advertisement Interval, and IPvX addresses of the Active Router
        associated with the VRID.
      </t>
      <t>
        When VRRP is protecting an IPv4 address, VRRP packets are sent
        encapsulated in IPv4 packets.  They are sent to the IPv4 multicast
        address assigned to VRRP.
      </t>
      <t>
        When VRRP is protecting an IPv6 address, VRRP packets are sent
        encapsulated in IPv6 packets.  They are sent to the IPv6 multicast
        address assigned to VRRP.
      </t>
      <section anchor="sect-5.1">
        <name>VRRP Packet Format</name>
        <t>
          This section defines the format of the VRRP packet and the relevant
          fields in the IPvX header (in conjunction with the address family).
        </t>

	<figure>
	  <name>IPv4/IPv6 VRRP Advertisement Packet Format</name>
        <artwork><![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    IPv4 Fields or IPv6 Fields                 |
 ...                                                             ...
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Version| Type  | Virtual Rtr ID|   Priority    |IPvX Addr Count|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Reserve| Max Advertise Interval|          Checksum             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                       IPvX Address(es)                        |
 +                                                               +
 +                                                               +
 +                                                               +
 +                                                               +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           IPv4/IPv6 VRRP Advertisement Packet Format
 ]]></artwork>
	</figure>
	<section anchor="sect-5.1.1">
	  <name>IPv4 Field Descriptions</name>
	  <section anchor="sect-5.1.1.1">
	    <name>Source Address</name>
	    <t>
	      This is the primary IPv4 address of the interface from which the packet is being
              sent.
            </t>
	  </section>
	  <section anchor="sect-5.1.1.2">
	    <name>Destination Address</name>
	    <t>
	      The IPv4 multicast address as assigned by the IANA for VRRP is:
            </t>
	    <t indent="4">
	      224.0.0.18
            </t>
	    <t>
	      This is a link-local scope multicast address.  Routers MUST NOT <bcp14>MUST NOT</bcp14>
              forward a datagram with this destination address, regardless of its
              TTL.
            </t>
	  </section>
	  <section anchor="sect-5.1.1.3">
	    <name>TTL</name>
	    <t>
	      The TTL MUST <bcp14>MUST</bcp14> be set to 255.  A VRRP Router receiving a packet with
              the TTL not equal to 255 MUST <bcp14>MUST</bcp14> discard the packet <xref target="RFC5082"/>.
            </t>
	  </section>
	  <section anchor="sect-5.1.1.4">
	    <name>Protocol</name>
	    <t>
	      The IPv4 protocol number assigned by the IANA for VRRP is 112
              (decimal).
            </t>
	  </section>
	</section>
	<section anchor="sect-5.1.2">
	  <name>IPv6 Field Descriptions</name>
	  <section anchor="sect-5.1.2.1">
	    <name>Source Address</name>
	    <t>
	      This is the IPv6 link-local address of the interface from which the packet is
              being sent.
            </t>
	  </section>
	  <section anchor="sect-5.1.2.2">
	    <name>Destination Address</name>
	    <t>
              The IPv6 multicast address assigned by the IANA for VRRP is:
            </t>
	    <t indent="4">
	      ff02:0:0:0:0:0:0:12
	    </t>
	    <t>
	      This is a link-local scope multicast address.  Routers MUST NOT <bcp14>MUST NOT</bcp14>
              forward a datagram with this destination address, regardless of its
              Hop Limit.
            </t>
	  </section>
	  <section anchor="sect-5.1.2.3">
	    <name>Hop Limit</name>
	    <t>
	      The Hop Limit MUST <bcp14>MUST</bcp14> be set to 255.  A VRRP Router receiving a packet
              with the Hop Limit not equal to 255 MUST <bcp14>MUST</bcp14> discard the
              packet <xref target="RFC5082"/>.
            </t>
	  </section>
	  <section anchor="sect-5.1.2.4">
	    <name>Next Header</name>
	    <t>
	      The IPv6 Next Header protocol assigned by the IANA for VRRP is 112
              (decimal).
            </t>
	  </section>
	</section>
      </section>
      <section anchor="sect-5.2">
	<name>VRRP Field Descriptions</name>
	<section anchor="sect-5.2.1">
	  <name>Version</name>
	  <t>
	    The version Version field specifies the VRRP protocol version of this packet.
            This document defines version 3.
          </t>
	</section>
	<section anchor="sect-5.2.2">
	  <name>Type</name>
	  <t>
	    The Type field specifies the type of this VRRP packet.  The only
            packet type defined in this version of the protocol is:
          </t>
	  <t indent="4">
	    1 - ADVERTISEMENT
          </t>
	  <dl newline="false">
	    <dt>1</dt><dd>- ADVERTISEMENT</dd>
          </dl>
	  <t>
	    A packet with unknown type MUST <bcp14>MUST</bcp14> be discarded.
          </t>
	</section>
	<section anchor="sect-5.2.3">
	  <name>Virtual Rtr ID (VRID)</name>
	  <t>
	    The Virtual Rtr ID field identifies the Virtual Router for which this
            packet is reporting status.
          </t>
	</section>
	<section anchor="sect-5.2.4">
	  <name>Priority</name>
	  <t>
	    The priority Priority field specifies the sending the VRRP Router's priority for
            the Virtual Router.  Higher values indicate higher priority.  This field
            is an 8-bit unsigned integer field.
          </t>
	  <t>
	    The priority value for the VRRP Router that owns the IPvX address
            associated with the Virtual Router MUST <bcp14>MUST</bcp14> be 255 (decimal).
          </t>
	  <t>
	    VRRP Routers backing up a Virtual Router MUST <bcp14>MUST</bcp14> use priority values
            between 1-254 (decimal).  The default priority value for VRRP Routers
            backing up a Virtual Router is 100 (decimal). Refer to <xref target="sect-8.3.2"/>
            for recommendations on setting the priority.
          </t>
	  <t>
	    The priority value zero (0) has special meaning, indicating that the
            current Active Router has stopped participating in VRRP.  This is used to
            trigger Backup Routers to quickly transition to the Active Router without having
            to wait for the current Active_Down_Interval (refer to <xref target="sect-6.1"/>).
          </t>
	</section>
	<section anchor="sect-5.2.5">
	  <name>IPvX Addr Count</name>
	  <t>
	    This
	    The IPvX Addr Count field is the number of either IPv4 addresses or IPv6 addresses
            contained in this VRRP advertisement.  The minimum value is 1.
            If the received count is 0, the VRRP advertisement MUST <bcp14>MUST</bcp14> be ignored.
          </t>
	</section>
	<section anchor="sect-5.2.6">
	  <name>Reserve</name>
	  <t>
	    This reserved
	    The Reserve field MUST <bcp14>MUST</bcp14> be set to zero on transmission and ignored on
            reception.
          </t>
	</section>
	<section anchor="sect-5.2.7">
	  <name>Maximum Advertisement Interval (Max Advertise Interval)</name>
	  <t>
	    The Maximum Advertisement Max Advertise Interval is a 12-bit field that indicates
            the time interval (in centiseconds) between advertisements.  The
            default is 100 centiseconds (1 second).
          </t>
	  <t>
	    Note that higher-priority Active Routers with slower transmission
            rates than their Backup Routers are unstable.  This is because
            lower-priority Backup Routers configured to faster rates could join the LAN and
            decide they should be Active Routers before they have heard anything from
            the higher-priority Active Router with a slower rate.  When this happens, it
            is temporary, i.e., once the lower-priority node does hear from the higher-priority
            Active Router, it will relinquish Active Router status.
          </t>
	</section>
	<section anchor="sect-5.2.8">
	  <name>Checksum</name>
	  <t>
	    The checksum Checksum field is used to detect data corruption in the VRRP
            message.
          </t>
	  <t>
	    For both the IPv4 and IPv6 address families, the checksum is the
            16-bit one's complement of the one's complement sum of the VRRP
            message. For computing the checksum,
            the checksum Checksum field is set to zero.  See RFC1071 <xref target="RFC1071"/> for more detail
            <xref target="RFC1071"/>. details.
          </t>
          <t>
            For the IPv4 address family, the checksum calculation only includes the
            VRRP message starting with the Version field and ending after the last
            IPv4 address (refer to <xref target="sect-5.2"/>).
          </t>
          <t>
            For the IPv6 address family, the checksum calculation also includes
            a prepended "pseudo-header" "pseudo-header", as defined in Section 8.1 of <xref target="RFC8200"/>. target="RFC8200" section="8.1" sectionFormat="of" />.
            The next header Next Header field in the "pseudo-header" should be set to 112 (decimal)
            for VRRP.
          </t>
	</section>
	<section anchor="sect-5.2.9">
	  <name>IPvX Address(es)</name>
	  <t>
	    This refers to one or more IPvX addresses associated with the Virtual
            Router.  The number of addresses included is specified in the
            "IPvX
            IPvX Addr Count" Count field.  These fields are used for troubleshooting
            misconfigured routers.  If more than one address is sent, it is
            recommended that all routers be configured to send these addresses in
            the same order to simplify comparisons.
          </t>
	  <t>
	    For IPv4 addresses, this refers to one or more IPv4 addresses that
            are backed up by the Virtual Router.
          </t>
	  <t>
	    For IPv6, the first address MUST <bcp14>MUST</bcp14> be the IPv6 link-local address
            associated with the Virtual Router.
          </t>
	  <t>
	    This field contains either one or more IPv4 addresses, addresses or one or more
            IPv6 addresses. The address family of the addresses, IPv4 or IPv6
            but not both, MUST <bcp14>MUST</bcp14> be the same as the VRRP packet's IPvX header
            address family.
          </t>
	</section>
      </section>
    </section>
    <section anchor="state-machine">
      <name>Protocol State Machine</name>
      <section anchor="sect-6.1">
	<name>Parameters Per per Virtual Router</name>
	<dl newline="false" spacing="normal" indent="28">
	  <dt>VRID</dt>
	  <dd>
	    <t>
	      Virtual Router Identifier.  Configurable
	      value in the range 1-255 (decimal).  There
              is no default.
	    </t>
	  </dd>
	  <dt>Priority</dt>
	  <dd>
	    <t>
	      Priority value to be used by this VRRP
	      router
	      Router in Active Router election for this
              Virtual Router.  The value of 255
              (decimal) is reserved for the router that
              owns the IPvX address associated with the
              Virtual Router.  The value of 0 (zero) is
              reserved for the Active Router to
              indicate it is relinquishing responsibility
              for the Virtual Router.  The range 1-254
              (decimal) is available for VRRP Routers
              backing up the Virtual Router.  Higher
              values indicate higher priorities.  The
              default value is 100 (decimal).
	    </t>
	  </dd>
	  <dt>IPv4_Addresses</dt>
	  <dd>
	    <t>
	      One or more IPv4 addresses associated
	      with this Virtual Router.  Configured
              list of addresses with no default.
	    </t>
	  </dd>
	  <dt>IPv6_Addresses</dt>
	  <dd>
	    <t>
	      One or more IPv6 addresses associated
	      with this Virtual Router.  Configured
              list of addresses with no default.  The first
              address MUST <bcp14>MUST</bcp14> be the Link-Local address
              associated with the Virtual Router.
	    </t>
	  </dd>
	  <dt>IPvX_Addresses</dt>
	  <dd>
	    <t>
	      Refer to either the IPv4 or IPv6 address associated
	      with this Virtual Router (see IPv4_Addresses and
              IPv6_Addresses above).
	    </t>
	  </dd>
	  <dt>Advertisement_Interval</dt>
	  <dd>
	    <t>
	      Time interval between ADVERTISEMENTS VRRP Advertisements
	      (centiseconds) sent by this Virtual Router.
              Default is 100 centiseconds (1 second).
	    </t>
	  </dd>
	  <dt>Active_Adver_Interval</dt>
	  <dd>
	    <t>
	      Advertisement interval contained in
	      ADVERTISEMENTS
	      VRRP Advertisements received from the Active
              Router (in centiseconds).  This value is saved by
              Virtual Routers in the Backup state and
              used to compute Skew_Time (as specfied specified in <xref target="sect-8.3.2"/>)
              and Active_Down_Interval.  The initial value
              is the same as Advertisement_Interval.
	    </t>
	  </dd>
	  <dt>Skew_Time</dt>
	  <dd>
	    <t>
	      Time to skew Active_Down_Interval in
	      centiseconds.  Calculated as:
            </t>
            <t indent="4">
	      (((256 - Priority) * Active_Adver_Interval) / 256)
	    </t>
	  </dd>
	  <dt>Active_Down_Interval</dt>
	  <dd>
	    <t>
	      Time interval for the Backup Router to declare
	      the Active Router down (centiseconds).
              Calculated as:
            </t>
            <t indent="4">
	      (3 * Active_Adver_Interval) + Skew_Time
	    </t>
	  </dd>
	  <dt>Preempt_Mode</dt>
	  <dd>
	    <t>
	      Controls whether a (starting or
	      restarting) higher-priority Backup Router
              preempts a lower-priority Active Router.
              Values are True to allow preemption and
              False to prohibit preemption.  Default is
              True.
	    </t>

	    <t>
	      Note: The exception is that the router
              that owns the IPvX address associated
              with the Virtual Router always preempts,
              independent of the setting of this flag.
	    </t>
	  </dd>
	  <dt>Accept_Mode</dt>
	  <dd>
	    <t>
	      Controls whether a Virtual Router in
	      Active state will accept packets
              addressed to the address owner's IPvX
              address as its own even if it is not the IPvX
              address owner.  The default is False.
              Deployments that rely on, for example,
              pinging the address owner's IPvX address
              may wish to configure Accept_Mode to
              True.
	    </t>
	    <t>
	      Note: IPv6 Neighbor Solicitations and
              Neighbor Advertisements MUST NOT <bcp14>MUST NOT</bcp14> be
              dropped when Accept_Mode is False.
	    </t>
	  </dd>
	  <dt>Virtual_Router_MAC_Address</dt>
	  <dd>
	    <t>
	      The MAC address used for the source MAC
	      address in VRRP advertisements and
              advertised in ARP/ND messages as
              the MAC address to use for IPvX_Addresses.
	    </t>
	  </dd>
	</dl>
      </section>
      <section anchor="sect-6.2">
	<name>Timers</name>
	<dl newline="false" spacing="normal" indent="25">
	  <dt>Active_Down_Timer</dt>
	  <dd>
	    <t>
	      Timer that fires when a VRRP Advertisement has not
	      been received for Active_Down_Interval (Backup Routers only).
	    </t>
	  </dd>
	  <dt>Adver_Timer</dt>
	  <dd>
	    <t>
	      Timer that fires to trigger transmission of
	      a VRRP Advertisement based on the Advertisement_Interval (Active Routers only).
	    </t>
	  </dd>
	</dl>
      </section>
      <section anchor="sect-6.3">
	<name>State Transition Diagram</name>
 	<figure>
 	  <name>State Transition Diagram</name>
	<artwork><![CDATA[
                   +---------------+
        +--------->|               |<-------------+
        |          |  Initialize   |              |
        |   +------|               |----------+   |
        |   |      +---------------+          |   |
        |   |                                 |   |
        |   V                                 V   |
   +---------------+                       +---------------+
   |               |---------------------->|               |
   |    Active     |                       |    Backup     |
   |               |<----------------------|               |
   +---------------+                       +---------------+
   ]]></artwork>
	</figure>
      </section>
      <section anchor="sect-6.4">
	<name>State Descriptions</name>
	<t>
	  In the state descriptions below, the state names are identified by
          {state-name}, and the packets are identified by all-uppercase
          characters.
        </t>
	<t>
	  A VRRP Router implements an instance of the state machine for each
          Virtual Router in which it is participating.
        </t>
	<section anchor="sect-6.4.1">
	  <name>Initialize</name>
	  <t>
	    The purpose of this state is to wait for a Startup event, that is, an
            implementation-defined mechanism that initiates the protocol once it
            has been configured.  The configuration mechanism is out of scope for
            this specification.
          </t>
          <artwork><![CDATA[
If
<t>If a Startup event is received, then:

    - If then:</t>
<ul>
  <li><t>If the Priority = 255, i.e., the router owns the IPvX
  address(es) associated with the Virtual Router, then:

       + Send then:</t>
  <ul>
    <li>Send an ADVERTISEMENT

       + If ADVERTISEMENT</li>
    <li><t>If the protected IPvX address is an IPv4 address, then:

         * For then:</t>
    <ul>
      <li>For each IPv4 address associated with the Virtual
      Router, broadcast a gratuitous ARP message
      containing the Virtual Router MAC address and
      with the target link-layer address set to the
      Virtual Router MAC address.

       + else address.</li>
    </ul></li>
    <li><t>else // IPv6

         * For IPv6</t>
    <ul>
      <li>For each IPv6 address associated with the Virtual
      Router, send an unsolicited ND Neighbor
      Advertisement with the Router Flag (R) set, the
      Solicited Flag (S) clear, the Override flag (O)
      set, the target address set to the IPv6 address
      of the Virtual Router, and the target link-layer
      address set to the Virtual Router MAC address.

       + endif address.</li>
    </ul></li>
    <li>endif // was protected address IPv4?

       + Set IPv4?</li>
    <li>Set the Adver_Timer to Advertisement_Interval

       + Transition Advertisement_Interval</li>
    <li>Transition to the {Active} state

    - else state</li>
  </ul></li>
  <li><t>else // Router is not the address owner

       + Set owner</t>
  <ul>
    <li>Set the Active_Adver_Interval to Advertisement_Interval

       + Set Advertisement_Interval</li>
    <li>Set the Active_Down_Timer to Active_Down_Interval

       + Transition Active_Down_Interval</li>
    <li>Transition to the {Backup} state

    - endif state</li>
  </ul></li>
  <li>endif // was priority 255?

endif 255?</li>
</ul>
<t>endif // Startup event was received
  ]]></artwork> received</t>

        </section>
      <section anchor="sect-6.4.2">
        <name>Backup</name>
        <t>
          The purpose of the {Backup} state is to monitor the availability and
          state of the Active Router. The Solicited-Node multicast address
          <xref target="RFC4291"/> is referenced in the pseudo-code pseudocode below.
        </t>
        <artwork><![CDATA[
While

<t>While in Backup the {Backup} state, a VRRP Router MUST <bcp14>MUST</bcp14> do the following:

    - If following:</t>
<ul>
  <li><t>If the protected IPvX address is an IPv4 address,
      then:

       + It MUST NOT
  then:</t>
  <ul>
    <li><t>It <bcp14>MUST NOT</bcp14> respond to ARP requests for the IPv4
    address(es) associated with the Virtual Router.

    - else Router.</t></li>
  </ul></li>
  <li><t>else // protected address is IPv6

       + It MUST NOT IPv6</t>
  <ul>
    <li>It <bcp14>MUST NOT</bcp14> respond to ND Neighbor Solicitation messages
    for the IPv6 address(es) associated with the Virtual Router.

       + It MUST NOT Router.</li>
    <li>It <bcp14>MUST NOT</bcp14> send ND Router Advertisement messages
    for the Virtual Router.

    - endif Router.</li>
  </ul></li>
  <li>endif // was protected address IPv4?

    - It MUST IPv4?</li>
  <li>It <bcp14>MUST</bcp14> discard packets with a destination link-layer
  MAC address equal to the Virtual Router MAC address.

    - It MUST NOT address.</li>
  <li>It <bcp14>MUST NOT</bcp14> accept packets addressed to the IPvX
  address(es) associated with the Virtual Router.

    - If Router.</li>
  <li><t>If a Shutdown event is received, then:

       + Cancel then:</t>
  <ul>
    <li>Cancel the Active_Down_Timer

       + Transition Active_Down_Timer</li>
    <li>Transition to the {Initialize} state

    - endif state</li>
  </ul></li>
  <li>endif // Shutdown event received

    - If received</li>
  <li><t>If the Active_Down_Timer fires, then:

       + Send then:</t>
  <ul>
    <li><t>Send an ADVERTISEMENT

       + If ADVERTISEMENT</t></li>
    <li><t>If the protected IPvX address is an IPv4 address, then:

          * For then:</t>
    <ul>
      <li>For each IPv4 address associated with the Virtual
      Router, broadcast a gratuitous ARP message
      containing the Virtual Router MAC address and
      with the target link-layer address set to the
      Virtual Router MAC address.

       + else address.</li>
    </ul></li>
    <li><t>else // IPv6

          * Compute IPv6</t>
    <ul>
      <li>Compute and join the Solicited-Node multicast
      address [RFC4291] <xref target="RFC4291"/> for the IPv6 address(es)
      associated with the Virtual Router.

          * For Router.</li>
      <li>For each IPv6 address associated with the
      Virtual Router, send an unsolicited ND Neighbor
      Advertisement with the Router Flag (R) set, the
      Solicited Flag (S) clear, the Override flag (O)
      set, the target address set to the IPv6 address
      of the Virtual Router, and the target link-layer
      address set to the Virtual Router MAC address.

       + endif address.</li>
    </ul></li>
    <li>endif // was protected address IPv4?

       + Set IPv4?</li>
    <li>Set the Adver_Timer to Advertisement_Interval

       + Transition Advertisement_Interval</li>
    <li>Transition to the {Active} state

    - endif state</li>
  </ul></li>
  <li>endif // Active_Down_Timer fired

    - If fired</li>
  <li><t>If an ADVERTISEMENT is received, then:

       + If then:</t>
  <ul>
    <li><t>If the Priority in the ADVERTISEMENT is 0, then:

          * Set then:</t>
    <ul>
      <li>Set the Active_Down_Timer to Skew_Time

       + else Skew_Time</li>
    </ul></li>
    <li><t>else // priority non-zero

          * If non-zero</t>
    <ul><li><t>If Preempt_Mode is False, or if the Priority in
    the ADVERTISEMENT is greater than or equal to the
    local Priority, then:

             @ Set then:</t>
    <ul>
      <li>Set the Active_Adver_Interval to the Max Advertise
      Interval contained in the ADVERTISEMENT

             @ Recompute ADVERTISEMENT</li>
      <li>Recompute the Skew_Time

             @ Recompute Skew_Time</li>
      <li>Recompute the Active_Down_Interval,

             @ Set Active_Down_Interval</li>
      <li>Set the Active_Down_Timer to Active_Down_Interval

          * else Active_Down_Interval</li>
    </ul></li>
    <li><t>else // preempt was true and priority was less
    than the local priority

             @ Discard the ADVERTISEMENT

          * endif priority</t>
    <ul>
      <li>Discard the ADVERTISEMENT</li>
    </ul></li>
    <li>endif // preempt test

       + endif test</li>
  </ul></li>
  <li>endif // was priority 0?

   - endif 0?</li>
  </ul></li>
  <li>endif // was advertisement received?

endwhile received?</li>
</ul>
<t>endwhile // Backup state
   ]]></artwork> {Backup} state</t>
      </section>
      <section anchor="sect-6.4.3">
        <name>Active</name>
        <t>
          While in the {Active} state, the router functions as the forwarding
          router for the IPvX address(es) associated with the Virtual Router.
        </t>
        <t>
          Note that in the Active {Active} state, the Preempt_Mode Flag is not
          considered.
        </t>
        <artwork><![CDATA[
While

	<t>While in Active the {Active} state, a VRRP Router MUST <bcp14>MUST</bcp14> do the following:

    - If following:</t>
<ul>
  <li><t>If the protected IPvX address is an IPv4 address, then:

       + It MUST then:</t>
  <ul>
    <li>It <bcp14>MUST</bcp14> respond to ARP requests for the IPv4
    address(es) associated with the Virtual Router.

    - else Router.</li>
  </ul></li>
  <li><t>else // IPv6

       + It MUST 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
    Virtual Router.

       + It MUST Router.</li>
    <li>It <bcp14>MUST</bcp14> respond to ND Neighbor Solicitation messages (with
    the Router Flag (R) set) for the IPv6 address(es) associated
    with the Virtual Router.

       + It MUST Router.</li>
    <li>It <bcp14>MUST</bcp14> send ND Router Advertisements for the Virtual
         Router.

       + If
    Router.</li>
    <li><t>If Accept_Mode is False:  MUST NOT False:</t>
    <ul>
    <li>It <bcp14>MUST NOT</bcp14> drop IPv6
    Neighbor Solicitations and Neighbor Advertisements.

    - endif Advertisements.</li>
    </ul></li>
  </ul></li>
  <li>endif // IPv4?

    - It MUST IPv4?</li>
  <li>It <bcp14>MUST</bcp14> forward packets with a destination link-layer MAC
  address equal to the Virtual Router MAC address.

    - It MUST address.</li>
  <li>It <bcp14>MUST</bcp14> accept packets addressed to the IPvX address(es)
  associated with the Virtual Router if it is the IPvX
  address owner or if Accept_Mode is True.  Otherwise,
      MUST NOT it
  <bcp14>MUST NOT</bcp14> accept these packets.

   - If packets.</li>
  <li><t>If a Shutdown event is received, then:

       + Cancel then:</t>
  <ul>
    <li>Cancel the Adver_Timer

       + Send Adver_Timer</li>
    <li>Send an ADVERTISEMENT with Priority = 0

       + Transition 0</li>
    <li>Transition to the {Initialize} state

    - endif state</li>
  </ul></li>
  <li>endif // shutdown received

    - If received</li>
  <li><t>If the Adver_Timer fires, then:

       + Send then:</t>
  <ul>
    <li>Send an ADVERTISEMENT

       + Reset ADVERTISEMENT</li>
    <li>Reset the Adver_Timer to Advertisement_Interval

    - endif Advertisement_Interval</li>
  </ul></li>
  <li>endif // advertisement timer fired

    - If fired</li>
  <li><t>If an ADVERTISEMENT is received, then:

       + If then:</t>
  <ul>
    <li><t>If the Priority in the ADVERTISEMENT is 0, then:

          * Send then:</t>
    <ul>
      <li>Send an ADVERTISEMENT

          * Reset ADVERTISEMENT</li>
      <li>Reset the Adver_Timer to Advertisement_Interval

       + else Advertisement_Interval</li>
    </ul></li>
    <li><t>else // priority was non-zero

          * If non-zero</t>
    <ul>
      <li><t>If the Priority in the ADVERTISEMENT is greater
      than the local Priority or the Priority in the
      ADVERTISEMENT is equal to the local Priority and
      the primary IPvX Address address of the sender is greater
      than the local primary IPvX Address address (based on an
      unsigned integer comparison of the IPvX addresses in
            network-byte
      network byte order), then:

             @ Cancel Adver_Timer

             @ Set then:</t>
      <ul>
	<li>Cancel Adver_Timer</li>
	<li>Set the Active_Adver_Interval to the Max Advertise
        Interval contained in the ADVERTISEMENT

             @ Recompute ADVERTISEMENT</li>
	<li>Recompute the Skew_Time

             @ Recompute Skew_Time</li>
	<li>Recompute the Active_Down_Interval</li>
	<li>Set the Active_Down_Interval

             @ Set Active_Down_Timer to Active_Down_Interval

             @ Transition Active_Down_Interval</li>
	<li>Transition to the {Backup} state

          * else state</li>
      </ul></li>
      <li><t>else // new Active Router logic

             @ Discard logic</t>
      <ul>
	<li>Discard the ADVERTISEMENT

             @ Send ADVERTISEMENT</li>
	<li>Send an ADVERTISEMENT immediately to assert
               Active
        the {Active} state to the sending VRRP Router and
        to update any learning bridges with the correct
        Active VRRP Router path.

          * endif path.</li>
      </ul></li>
      <li>endif // new Active Router detected

       + endif detected</li>
    </ul></li>
    <li>endif // was priority zero?

    - endif zero?</li>
  </ul></li>
  <li>endif // advert received

endwhile received</li>
</ul>

<t>endwhile // in Active state
   ]]></artwork> {Active} state</t>
        <t>
          Note: VRRP packets are transmitted with the Virtual Router MAC
          Address
          address as the source MAC address to ensure that learning bridges
          correctly determine the LAN segment to which the Virtual Router is
          attached.
        </t>
      </section>
    </section>
  </section>
    <section anchor="sect-7">
      <name>Sending and Receiving VRRP Packets</name>
      <section anchor="sect-7.1">
        <name>Receiving VRRP Packets</name>
        <t>
          The following functions must be performed when a VRRP packet is received:
        </t>
        <artwork><![CDATA[
- If
<ul>
  <li><t>If the received packet is an IPv4 packet, then:

   + It MUST then:</t>
  <ul>
    <li>It <bcp14>MUST</bcp14> verify that the IPv4 TTL is 255.

- else 255.</li>
  </ul></li>
  <li><t>else // IPv6 VRRP packet received

  + It MUST received</t>
  <ul>
    <li>It <bcp14>MUST</bcp14> verify that the IPv6 Hop Limit is 255.

-endif

- It MUST 255.</li>
  </ul></li>
  <li>endif</li>
  <li>It <bcp14>MUST</bcp14> verify that the VRRP Version version is 3.

- It MUST 3.</li>
  <li>It <bcp14>MUST</bcp14> verify that the VRRP Packet Type packet type is 1 (ADVERTISEMENT).

- It MUST (ADVERTISEMENT).</li>
  <li>It <bcp14>MUST</bcp14> verify that the received packet contains the complete
  VRRP packet (including fixed fields, fields and the IPvX address).

- It MUST address).</li>
  <li>It <bcp14>MUST</bcp14> verify the VRRP checksum.

- It MUST checksum.</li>
  <li>It <bcp14>MUST</bcp14> verify that the VRID is configured on the receiving
  interface and the local router is not the IPvX address
  owner (Priority = 255 (decimal)).

If (decimal)).</li>
</ul>

<t>If any one of the above checks fails, the receiver MUST <bcp14>MUST</bcp14> discard
the packet, SHOULD <bcp14>SHOULD</bcp14> log the event (subject to rate-limiting), and
MAY
<bcp14>MAY</bcp14> indicate via network management that an error occurred.
   ]]></artwork> occurred.</t>
        <t>
          A receiver SHOULD <bcp14>SHOULD</bcp14> also verify that the Max Advertise Interval
          in the received VRRP packet matches the Advertisement_Interval
          configured for the VRID. Instability can occur with differing intervals
          (refer to <xref target="sect-5.2.7"/>).
          If this check fails, the receiver SHOULD <bcp14>SHOULD</bcp14> log the event (subject to
          rate-limiting) and MAY <bcp14>MAY</bcp14> indicate via network management that a
          misconfiguration was detected.
        </t>
        <t>
          A receiver MAY <bcp14>MAY</bcp14> also verify that "IPvX Addr Count" and the list
          of IPvX address(es) match the IPvX Address(es) address(es) configured for the VRID.
          If this check fails, the receiver SHOULD <bcp14>SHOULD</bcp14> log (subject to rate-limiting) the event
          and MAY <bcp14>MAY</bcp14> indicate via network management that a misconfiguration was detected.
        </t>
      </section>
      <section anchor="sect-7.2">
        <name>Transmitting VRRP Packets</name>
        <t>
          The following operations MUST <bcp14>MUST</bcp14> be performed when transmitting a VRRP
          packet:
        </t>
        <artwork><![CDATA[
- Fill
<ul>
  <li>Fill in the VRRP packet fields with the appropriate Virtual
  Router configuration state

- Compute state</li>
  <li>Compute the VRRP checksum

- Set checksum</li>
  <li>Set the source MAC address to the Virtual Router MAC Address

- If address</li>
  <li><t>If the protected address is an IPv4 address, then:

   + Set then:</t>
  <ul>
    <li>Set the source IPv4 address to the interface's primary IPv4
     address

- else
    address</li>
  </ul></li>
  <li><t>else // IPv6

    + Set IPv6</t>
  <ul>
    <li>Set the source IPv6 address to the interface's link-local
    IPv6 address

- endif

- Set address</li>
  </ul></li>
  <li>endif</li>
  <li>Set the IPvX protocol to VRRP

- Send VRRP</li>
  <li>Send the VRRP packet to the VRRP IPvX multicast group
      ]]></artwork> group</li>
</ul>
        <t>
          Note: VRRP packets are transmitted with the Virtual Router MAC
          address as the source MAC address to ensure that learning bridges
          correctly determine the LAN segment to which the Virtual Router is
          attached.
        </t>
      </section>
      <section anchor="sect-7.3">
        <name>Virtual Router MAC Address</name>
        <t>
          The Virtual Router MAC address associated with a Virtual Router is an
          IEEE 802 MAC Address address <xref target="I-D.ietf-intarea-rfc7042bis"/> target="RFC9542"/> in the
          following format:
        </t>
        <t>
          IPv4 case: 00-00-5E-00-01-{VRID} (in hex, in Internet-standard bit- network byte order)
        </t>
        <t>
          The first three octets are derived from the IANA's Organizational Organizationally
          Unique Identifier (OUI).  The next two octets (00-01) indicate the
          address block assigned to the VRRP protocol for the IPv4 protocol.
          {VRID} is the Virtual Router Identifier.  This mapping provides
          for up to 255 IPv4 VRRP Routers on a LAN.
        </t>
        <t>
          IPv6 case: 00-00-5E-00-02-{VRID} (in hex, in Internet-standard bit- network byte order)
        </t>
        <t>
          The first three octets are derived from the IANA's OUI.  The next two
          octets (00-02) indicate the address block assigned to the VRRP protocol for
          the IPv6 protocol. {VRID} is the Virtual Router Identifier.  This
          mapping provides for up to 255 IPv6 VRRP Routers on a LAN.
        </t>
      </section>
      <section anchor="sect-7.4">
        <name>IPv6 Interface Identifiers</name>
        <t>
          <xref target="RFC8064"/> specifies that <xref target="RFC7217"/> be used
          as the default scheme for generating a stable address in IPv6 Stateless
          Address Autoconfiguration (SLAAC) <xref target="RFC4862"/>.
          The Virtual Router MAC MUST NOT <bcp14>MUST NOT</bcp14> be used for the Net_Iface parameter used
          in the Interface Identifier (IID) derivation algorithms in
          <xref target="RFC7217"/> and <xref target="RFC8981"/>.
        </t>
        <t>
          Similarly, the Virtual Router MAC MUST NOT be used for the Net_Iface parameter
          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
          VRRP Router's IPv6 link-local address and other associated IPv6
          addresses into the Virtual Router MAC address.
        </t>
      </section>
    </section>
    <section anchor="sect-8">
      <name>Operational Issues</name>
      <section anchor="sect-8.1">
        <name>IPv4</name>
        <section anchor="sect-8.1.1">
          <name>ICMP Redirects</name>
          <t>
            ICMP redirects can be used normally when VRRP is running among a
            group of routers.  This allows VRRP to be used in environments where
            the topology is not symmetric.
          </t>
          <t>
            The IPv4 source address of an ICMP redirect should be the address
            that the end-host used when making its next-hop routing decision.  If
            a VRRP Router is acting as the Active Router for Virtual Router(s) containing
            address(es) it does not own, then it must determine to which Virtual
            Router the packet was sent when selecting the redirect source
            address.  One method to deduce the Virtual Router used is to examine
            the destination MAC address in the packet that triggered the
            redirect.
          </t>
          <t>
            It may be useful to disable redirects for specific cases where VRRP
            is being used to load-share traffic among a number of routers in a
            symmetric topology.
          </t>
        </section>
        <section anchor="sect-8.1.2">
          <name>Host ARP Requests</name>
          <t>
            When a host sends an ARP request for one of the Virtual Router IPv4
            addresses, the Active Router MUST <bcp14>MUST</bcp14> respond to the ARP request
            with an ARP response that indicates the Virtual Router MAC address for the
            Virtual Router.  Note that the source address of the Ethernet frame
            of this ARP response is the physical MAC address of the physical
            router.  The Active Router MUST NOT <bcp14>MUST NOT</bcp14> respond with its physical
            MAC address in the ARP response.  This allows the host to always
            use the same MAC address address, regardless of the current Active Router.
          </t>
          <t>
            When a VRRP Router restarts or boots, it SHOULD NOT <bcp14>SHOULD NOT</bcp14> send any ARP
            messages using its physical MAC address for an IPv4 address for
            which it is the IPv4 Address Owner address owner (as defined in <xref target="sect-1.7"/>),
            and it should only send ARP messages that include Virtual Router MAC addresses.
          </t>
          <t>
            This entails the following:
          </t>
          <ul spacing="normal">
            <li>
              When configuring an interface, Active Routers
              SHOULD
              <bcp14>SHOULD</bcp14> broadcast a gratuitous ARP message containing the Virtual
              Router MAC address for each IPv4 address on that interface.
            </li>
            <li>
              At system boot, when initializing interfaces for VRRP operation,
              gratuitous ARP messages MUST <bcp14>MUST</bcp14> be delayed until both the
              IPv4 address and the Virtual Router MAC address are configured.
            </li>
            <li>
              When, for example, SSH Secure Shell (SSH) access to a particular VRRP Router is
              required, an IPv4 address known to belong to that router SHOULD <bcp14>SHOULD</bcp14> be
              used.
            </li>
          </ul>
        </section>
        <section anchor="sect-8.1.3">
          <name>Proxy ARP</name>
          <t>
            If Proxy ARP is to be used on a VRRP Router, then the VRRP Router
            MUST
            <bcp14>MUST</bcp14> advertise the Virtual Router MAC address in the Proxy ARP
            message.  Doing otherwise could cause hosts to learn the real MAC
            address of the VRRP Router.
          </t>
        </section>
      </section>
      <section anchor="sect-8.2">
        <name>IPv6</name>
        <section anchor="sect-8.2.1">
          <name>ICMPv6 Redirects</name>
          <t>
            ICMPv6 redirects can be used normally when VRRP is running among a
            group of routers <xref target="RFC4443"/>.  This allows VRRP to be used in
            environments where the topology is not symmetric, e.g., the VRRP
            routers
            Routers do not connect to the same destinations.
          </t>
          <t>
            The IPv6 source address of an ICMPv6 redirect SHOULD <bcp14>SHOULD</bcp14> be the address
            that the end-host used when making its next-hop routing decision.  If
            a VRRP Router is acting as the Active Router for Virtual Router(s) containing
            address(es) it does not own, then it has to determine to which Virtual
            Router the packet was sent when selecting the redirect source
            address.  A method to deduce the Virtual Router used is to examine
            the destination MAC address in the packet that triggered the
            redirect.
          </t>
        </section>
        <section anchor="sect-8.2.2">
          <name>ND Neighbor Solicitation</name>
          <t>
            When a host sends an ND Neighbor Solicitation message for a Virtual
            Router IPv6 address, the Active Router MUST <bcp14>MUST</bcp14> respond to the ND
            Neighbor Solicitation message with the Virtual Router MAC address for the
            Virtual Router.  The Active Router MUST NOT <bcp14>MUST NOT</bcp14> respond with its
            physical MAC address.  This allows the host to always use the same
            MAC address address, regardless of the current Active Router.
          </t>
          <t>
            When an Active Router sends an ND Neighbor Solicitation
            message for a host's IPv6 address, the Active Router MUST <bcp14>MUST</bcp14>
            include the Virtual Router MAC address for the Virtual Router if it sends a
            source link-layer address option in the neighbor solicitation Neighbor Solicitation
            message.  It MUST NOT <bcp14>MUST NOT</bcp14> use its physical MAC address in the source
            link-layer address option.
          </t>
          <t>
            When a VRRP Router restarts or boots, it SHOULD NOT <bcp14>SHOULD NOT</bcp14> send any ND
            messages with its physical MAC address for the IPv6 address it owns
            and it should only send ND messages that include Virtual Router MAC addresses.
          </t>
          <t>
          This entails the following:</t>
          <ul spacing="normal">
            <li>
              When configuring an interface, Active Routers
              SHOULD
              <bcp14>SHOULD</bcp14> send an unsolicited ND Neighbor Advertisement message
              containing the Virtual Router MAC address for the IPv6 address on
              that interface.
            </li>
            <li>
              At system boot, when initializing interfaces for VRRP operation,
              all ND Router and Advertisements, ND Neighbor Advertisements Advertisements, and ND Neighbor Solicitation
              messages MUST <bcp14>MUST</bcp14> be delayed until both the IPv6 address and the
              Virtual Router MAC address are configured.
            </li>
          </ul>
          <t>
            Note that on a restarting Active Router where the VRRP protected
            address is an interface address, i.e., the address owner, Duplicate
            Address Detection may fail, as the Backup Router MAY <bcp14>MAY</bcp14> answer
            that it owns the address.  One solution is to not run Duplicate
            Address Detection in this case.
          </t>
        </section>
        <section anchor="sect-8.2.3">
          <name>Router Advertisements</name>
          <t>
            When a Backup VRRP Router has become the Active Router for a Virtual Router, it
            is responsible for sending Router Advertisements for the Virtual
            Router
            Router, as specified in <xref target="sect-6.4.3"/>.  The Backup Routers MUST <bcp14>MUST</bcp14> be
            configured to send the same Router Advertisement options as the
            address owner.
          </t>
          <t>
            Router Advertisement options that advertise special services, e.g.,
            Home Agent Information Option, that are present in the address owner
            SHOULD NOT
            <bcp14>SHOULD NOT</bcp14> be sent by the address owner unless the Backup Routers are
            prepared to assume these services in full and have a complete and
            synchronized database for this service.
          </t>
        </section>
        <section anchor="sect-8.2.4">
          <name>Unsolicited Neighbor Advertisements</name>
          <t>
            A VRRP Router acting as either an IPv6 Active Router or Backup Router, SHOULD Router <bcp14>SHOULD</bcp14>
            accept Unsolicited Neighbor Advertisements and update the corresponding
            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-routers multicast address (ff02::2), they will be received. Unsolicited
            Neighbor Advertisements are sent both in the case where the link-level addresses
            change <xref target="RFC4861"/> and for gratuitous neighbor discovery by first hop first-hop
            routers <xref target="RFC9131"/>. Additional configuration may be required in order
            for Unsolicited Neighbor Advertisements to update the corresponding neighbor cache.
          </t>
        </section>
      </section>
      <section anchor="sect-8.3">
        <name>IPvX</name>
        <section anchor="sect-8.3.1">
          <name>Potential Forwarding Loop</name>
          <t>
            If it is not the address owner, a VRRP Router SHOULD NOT <bcp14>SHOULD NOT</bcp14> forward
            packets addressed to the IPvX address for which it becomes the Active Router.
            Forwarding these packets would result in unnecessary traffic.  Also,
            in the case of LANs that receive packets they transmit, this can result
            in a forwarding loop that is only terminated when the IPvX TTL expires.
          </t>
          <t>
            One mechanism for VRRP Routers to avoid these forwarding loops is to add/delete
            a host Drop Route for each non-owned IPvX address when transitioning
            to/from the Active state.
          </t>
        </section>
        <section anchor="sect-8.3.2">
          <name>Recommendations Regarding Setting Priority Values</name>
          <t>
            A priority value of 255 designates a particular router as the "IPvX address owner"
            for the VRID. VRRP Routers with priority 255 will, as soon as they start up, preempt all
            lower-priority routers.  For a VRID, only a single VRRP Router on the link SHOULD <bcp14>SHOULD</bcp14> be
            configured with priority 255. If multiple VRRP Routers advertising priority 255 are
            detected, the condition SHOULD <bcp14>SHOULD</bcp14> be logged (subject to rate-limiting). If no VRRP Router
            has this priority, and preemption is disabled, then no preemption will occur.
          </t>
          <t>
            In order to avoid two or more Backup Routers simultaneously becoming Active Routers after
            the previous Active Router fails or is shut down, all Virtual Routers SHOULD <bcp14>SHOULD</bcp14> be configured
            with different priorities, priorities and with sufficient differences in priority the priorities so that lower
            priority Backup Routers do not transition to the Active state before receiving an advertisement
            from the highest priority Backup Router following when it transitioning transitions to the Active Router. If
            multiple VRRP Routers advertising the same priority are detected, this condition MAY <bcp14>MAY</bcp14>
            be logged as a warning (subject to rate-limiting).
          </t>
          <t>
            Since the Skew_Time is reduced as the priority is increased, faster
            convergence can be obtained by using a higher priority for the preferred
            Backup Router. However, with multiple Backup Routers, the priorities should have
            sufficient differences differences, as previously recommended.
          </t>
        </section>
      </section>
      <section anchor="sect-8.4">
        <name>VRRPv3 and VRRPv2 Interoperation</name>
        <section anchor="sect-8.4.1">
          <name>Assumptions</name>
          <ol spacing="normal" type="1">
            <li>
              VRRPv2 and VRRPv3 interoperation is optional.
            </li>
            <li>
              Mixing VRRPv2 and VRRPv3 should only be done when transitioning
              from VRRPv2 to VRRPv3.  Mixing the two versions should not be
              considered a permanent solution.
            </li>
          </ol>
        </section>
        <section anchor="sect-8.4.2">
          <name>VRRPv3 Support of VRRPv2 Interoperation</name>
          <t>
            As mentioned above, this support is intended for upgrade scenarios
            and is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> for permanent deployments.
          </t>
          <t>
            An implementation MAY <bcp14>MAY</bcp14> implement a configuration flag that tells it to
            listen for and send both VRRPv2 and VRRPv3 advertisements.
          </t>
          <t>
            When a Virtual Router is configured this way and is the Active Router, it
            MUST
            <bcp14>MUST</bcp14> send both types at the configured rate, even if it is sub-second.
          </t>
          <t>
            When a Virtual Router is configured this way and is the Backup Router, it
            MUST
            <bcp14>MUST</bcp14> time out based on the rate advertised by the Active Router. In the
            case of a VRRPv2 Active Router, this means it MUST <bcp14>MUST</bcp14> translate the timeout
            value it receives (in seconds) into centiseconds.  Also, a Backup
            Router SHOULD <bcp14>SHOULD</bcp14> ignore VRRPv2 advertisements from the current Active Router
            if it is also receiving VRRPv3 packets from it.  It MAY <bcp14>MAY</bcp14> report when a VRRPv3
            Active Router is not sending VRRPv2 packets packets, as this suggests they don't
            agree on whether they're supporting VRRPv2 interoperation.
          </t>
          <section anchor="sect-8.4.3">
            <name>Interoperation Considerations</name>
            <section anchor="sect-8.4.3.1">
              <name>Slow, High-Priority Active Routers</name>
              <t>
                See also <xref target="sect-5.2.7"/>,
                "Maximum Advertisement Interval (Max Advertise Interval)".
              </t>
              <t>
                The VRRPv2 Active Router interacting with a sub-second VRRPv3 Backup
                router
                Router is the most important example of this.
              </t>
              <t>
                A VRRPv2 implementation SHOULD NOT <bcp14>SHOULD NOT</bcp14> be given a higher priority than a
                VRRPv2/VRRPv3
                VRRPv2 or VRRPv3 implementation with which it is interoperating if the
                VRRPv2/VRRPv3
                VRRPv2 or VRRPv3 router's advertisement rate is sub-second.
              </t>
            </section>
            <section anchor="sect-8.4.3.2">
              <name>Overwhelming VRRPv2 Backups</name>
              <t>
                It seems possible that a VRRPv3 Active Router sending at centisecond
                rates could potentially overwhelm a VRRPv2 Backup Router with
                potentially non-deterministic results.
              </t>
              <t>
                In this upgrade case, a deployment should initially run the VRRPv3
                Active Routers with lower frequencies, e.g., 100 centiseconds, until
                the VRRPv2 routers are upgraded.  Then, once the deployment has
                verified that VRRPv3 is working properly, the VRRPv2 support
                may be disabled and the desired sub-second rates may be configured.
              </t>
            </section>
          </section>
        </section>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        VRRP for IPvX does not currently include any type of authentication.
        Earlier versions of the VRRP specification included
        several types of authentication authentication, ranging from no authentication to strong
        authentication.
        Operational experience and further analysis determined that these did
        not provide sufficient security to overcome the vulnerability of
        misconfigured secrets, causing multiple Active Routers to be elected.
        Due to the nature of the VRRP protocol, even if VRRP messages are
        cryptographically protected, it does not prevent hostile nodes from
        behaving as if they are an Active Router, creating multiple
        Active Routers.  Authentication of VRRP messages could have prevented
        a hostile node from causing all properly functioning routers from going
        into the Backup state.  However, having multiple Active Routers can cause
        as much disruption as no routers, which authentication cannot prevent.
        Also, even if a hostile node could not disrupt VRRP, it can disrupt ARP/ND
        and create the same effect as having all routers go into the Backup state.
      </t>
      <t>
        Some L2 switches provide the capability to filter out, for example,
        ARP and/or ND messages from end-hosts on a switch-port basis.  This
        mechanism could also filter VRRP messages from switch ports
        associated with end-hosts and can be considered for deployments with
        untrusted hosts.
      </t>
      <t>
        It should be noted that these attacks are not worse and are a subset
        of the attacks that any node attached to a LAN can do independently
        of VRRP.  The kind of attacks a malicious node on a LAN can perform
        include:
      </t>
      <ul spacing="normal">
        <li>
          Promiscuously
          promiscuously receiving packets for any router's MAC address. address,
        </li>
        <li>
          Sending
          sending packets with the router's MAC address as the source MAC
          address in the L2 header to tell the L2 switches to send packets
          addressed to the router to the malicious node instead of the router. router,
        </li>
        <li>
          Sending
          sending redirects to tell hosts to send their traffic
          somewhere else. else,
        </li>
        <li>
          Sending
          sending unsolicited ND replies. replies,
        </li>
        <li>
          Answering
          answering ND requests, etc.
	</li>
      </ul>
      <t>
        All of these can be done independently of implementing VRRP.
        VRRP does not add to these vulnerabilities vulnerabilities, and most of these
        vulnerabilities are addressed independently, e.g., SEcure Neighbor Discovery (SEND)
        <xref target="RFC3971"/>.
      </t>
      <t>
        VRRP includes a mechanism
        (setting IPv4 TTL or IPv6 Hop Limit to 255 and checking the value on receipt)
        that protects against VRRP packets being injected from another remote
        network  <xref target="RFC5082"/>.
        This limits most vulnerabilities to attacks on the local
        network.
      </t>
      <t>
        VRRP does not provide any confidentiality.  Confidentiality is not
        necessary for the correct operation of VRRP, and there is no
        information in the VRRP messages that must be kept secret from other
        nodes on the LAN.
      </t>
      <t>
        In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND) SEND
        is deployed, VRRP is compatible with the "trust anchor" and "trust
        anchor or CGA" modes of SEND <xref target="RFC3971"/>.  The SEND
        configuration needs to give the Active and Backup Routers the same prefix
        delegation in the certificates so that Active and Backup Routers advertise
        the same set of subnet prefixes.  However, the Active and Backup Routers
        should have their own key pairs to avoid private key sharing.
      </t>
      <t>
        Also in the context of IPv6 operation, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the
        link-level security guidelines in section 2.3 of <xref target="RFC9099"/> target="RFC9099" section="2.3" sectionFormat="of" />
        be followed.
      </t>
    </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 Nordmark,
        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 Okonnikov,
        Ben Niven-Jenkins, Tim Chown, Malisa Vucinic, Russ White, Donald Eastlake, 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 related to the removal
        of legacy technology appendices. Thanks to Dhruv Dhody and Donald Eastlake 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 comments on the
        current document (RFC 5798 BIS).
      </t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
        IANA is requested to update has updated all IANA Registry registry references to <xref target="RFC5798"/>
        to be references to [RFCXXXX], RFC 9568, i.e., this document. The individual IANA
        references are listed below.
      </t>
      <t>
        The value 112 is assigned to VRRP in the Assigned "Assigned Internet Protocol Numbers Registry. Numbers" registry.
      </t>
      <t>
        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 has assigned
        the IPv4 multicast address 224.0.0.18 for VRRP.
      </t>
      <t>
        In the "Link-Local Scope Multicast Addresses" block registry of the "IPv6 Multicast Address
        Space Registry" <xref target="RFC3307"/>, IANA has assigned the IPv6 link-local
        scope multicast address ff02:0:0:0:0:0:0:12 for VRRP for IPv6.
      </t>
      <t>
        In the "IANA MAC ADDRESS BLOCK" registry <xref target="I-D.ietf-intarea-rfc7042bis"/>, target="RFC9542"/>,
        IANA has assigned blocks of Ethernet unicast addresses as
        follows (in hexadecimal):
      </t>
      <artwork><![CDATA[
      00-01-00 to 00-01-FF VRRP
      00-02-00
<table anchor="table_iana_64_bit_macs">
  <thead>
    <tr>
      <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 VRRP 00-02-FF</td>
      <td>VRRP IPv6
      ]]></artwork> (Virtual Router Redundancy Protocol
IPv6)</td>
      <td>RFC 9568</td>
    </tr>
  </tbody>
  </table>
    </section>
</middle>
<back>
  <references title="Normative References">
  <displayreference target="I-D.ietf-vrrp-ipv6-spec" to="VRRP-IPv6"/>
   <references>
    <name>References</name>
    <references>
      <name>Normative References</name>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3307.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3307.xml"/>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4291.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4443.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4861.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5082.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"/>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5771.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5771.xml"/>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8200.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-rfc7042bis.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9542.xml"/>

</references>
<references>
  <name>Informative References</name>

<!-- [VRRP-IPv6] draft-ietf-vrrp-ipv6-spec-08  	IESG state: Expired (IESG: Dead)
Long way used to fix Bob Hinden's initials-->
<reference anchor="VRRP-IPv6"> 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>
<author fullname="Robert Hinden" initials="R." surname="Hinden" fullname="R. Hinden"> surname="Hinden">
<organization>Nokia</organization>
</author>
<author fullname="John Cruz" initials="J." surname="Cruz" fullname="J. Cruz"> surname="Cruz">
<organization>Cisco Systems</organization>
</author>
<date day="5" month="March" year="2007"/>
</front>
<seriesInfo name="Work" value="in Progress"/> name="Internet-Draft" value="draft-ietf-vrrp-ipv6-spec-08"/>
</reference>

  <reference anchor="IPSTB">
  <front>
    <title>Development of Router Clusters to Provide Fast Failover in IP Networks",
    Digital Technical Journal, Volume 9 Number 3 Networks
</title>
<author>
<organization>Higginson, P. and M. Shand</organization>
<author initials="P" surname="Higginson" fullname="Peter L. Higginson">
  <organization/>
</author>
<author initials="M" surname="Shand" fullname="Michael C. Shand">
  <organization/>
</author>
<date year="1997"/>
  </front>
  <refcontent>Digital Technical Journal, Volume 9, Number 3</refcontent>
</reference>

<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1071.xml"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> 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"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9131.xml"/>

<reference anchor="NISTIR8366" target="https://doi.org/10.6028/NIST.IR.8366"> anchor="NISTIR8366">
  <front>
    <title>Guidance for NIST Staff on Using Inclusive Language in Documentary Standards,
National
</title>
<author>
  <organization>National Institute of Standards and Technology (NIST) Interagency or Internal Report 8366</title>
<author surname="NIST"/> (NIST)</organization>
</author>
<date year="2021" month="April"/>
</front>
<seriesInfo name="NISTIR" value="8366"/>
<seriesInfo name="DOI" value="10.6028/NIST.IR.8366"/>
</reference>
</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 fullname="R. Hinden"/>,
        <contact fullname="D. Mitzel"/>, <contact fullname="P. Hunt"/>, <contact fullname="P. Higginson"/>, <contact fullname="M. Shand"/>, and <contact fullname="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"/>, <contact fullname="Mukesh
        Gupta"/>, <contact fullname="Don Provan"/>, <contact fullname="Mark Hollinger"/>, <contact fullname="John Cruz"/>, and <contact fullname="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 <contact fullname="Glen Zorn"/>, <contact fullname="Michael
        Lane"/>, <contact fullname="Clark Bremer"/>, <contact fullname="Hal Peterson"/>, <contact fullname="Tony Li"/>, <contact fullname="Barbara Denny"/>, <contact fullname="Joel
        Halpern"/>, <contact fullname="Steve M. Bellovin"/>, <contact fullname="Thomas Narten"/>, <contact fullname="Rob Montgomery"/>, <contact fullname="Rob Coltun"/>,
        <contact fullname="Radia Perlman"/>, <contact fullname="Russ Housley"/>, <contact fullname="Harald Alvestrand"/>, <contact fullname="Ned
        Freed"/>, <contact fullname="Ted Hardie"/>, <contact fullname="Bert Wijnen"/>, <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 eventually became
        <xref target="RFC5798"/>.
      </t>
      <t>
        Thanks to <contact fullname="Stewart Bryant"/>, <contact fullname="Sasha Vainshtein"/>, <contact fullname="Pascal Thubert"/>, <contact fullname="Alexander Okonnikov"/>,
        <contact fullname="Ben Niven-Jenkins"/>, <contact fullname="Tim Chown"/>, <contact fullname="Mališa Vučinić"/>, <contact fullname="Russ White"/>, <contact 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 Congdon"/>, and <contact fullname="Jon Rosen"/> for discussions related to the removal
        of legacy technology appendices. Thanks to <contact fullname="Dhruv Dhody"/> and <contact fullname="Donald Eastlake"/> for
        comments and suggestions for improving the IANA section. Thanks to <contact 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>
</rfc>