rfc-5798

Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

S. Nadas (Editor)
date2010-03 streamIETF areartg wgvrrp statusPROPOSED STANDARD pages40 canonicalhttps://www.rfc-editor.org/rfc/rfc5798 doi10.17487/RFC5798 errataview
This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]

obsoleted by

obsoletes

Extracted elements (29)

design-rationale §9

Authentication was deliberately removed from VRRPv3. Even cryptographically authenticated VRRP could not prevent a hostile node from behaving as a Master; multiple Masters are as disruptive as no routers. Additionally, misconfigured shared secrets in VRRPv2 caused spurious multiple-Master elections.

routing, security

design-rationale §3

IPv4 and IPv6 virtual router instances are independent domains within a VRRP router; the same VRID number may be reused for both address families on the same LAN because they are treated as two separate virtual routers. This avoids cross-family interference.

routing, ip

design-rationale §2.4

The virtual router MAC address is used as the source MAC in all VRRP messages and ARP/ND responses so that learning bridges correctly track which segment the virtual router is on. Using the physical MAC would result in bridge flooding for all traffic destined to the virtual router.

routing

design-rationale §1.3

VRRPv3 was extended to support IPv6 because standard IPv6 Neighbor Discovery unreachability detection takes approximately 38 seconds with default parameters before switching to an alternate router. VRRP provides failover in approximately 3 seconds without host involvement.

routing, ip

interoperability-note §8.4

VRRPv3 and VRRPv2 interoperation is optional and intended only for upgrade transition scenarios. Mixing versions should not be a permanent deployment. VRRPv2 Masters advertise intervals in seconds while VRRPv3 uses centiseconds, requiring conversion. Sub-second VRRPv3 rates may overwhelm VRRPv2 Backup routers.

routing

normative-requirement §6.4.2 MUST

A Backup router receiving an ADVERTISEMENT with Priority=0 from the Master MUST set its Master_Down_Timer to Skew_Time only (instead of Master_Down_Interval) to accelerate its transition to Master.

routing

normative-requirement §5.2.2 MUST

A VRRP packet with an unknown Type field MUST be discarded.

routing

normative-requirement §5.1.1.3 MUST

For IPv4, the TTL MUST be set to 255. A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet.

routing, ip, security

normative-requirement §5.1.2.3 MUST

For IPv6, the Hop Limit MUST be set to 255. A VRRP router receiving a packet with the Hop Limit not equal to 255 MUST discard the packet.

routing, ip, security

normative-requirement §5.2.9 MUST NOT

IPv4 addresses and IPv6 addresses MUST NOT both be carried in one IPvX Address field; a single VRRP message carries either IPv4 or IPv6 addresses, not both.

routing, ip

normative-requirement §7.4 MUST NOT

IPv6 routers running VRRP MUST create their Interface Identifiers in the normal manner and MUST NOT use the virtual router MAC address to create EUI-64 identifiers.

routing, ip

normative-requirement §7.1 MUST

On packet reception, the receiver MUST verify: TTL/Hop Limit = 255, VRRP version = 3, packet completeness, VRRP checksum, and that the VRID is configured on the interface. Any check failure MUST cause the packet to be discarded.

routing, security

normative-requirement §5.1.1.2 MUST NOT

Routers MUST NOT forward a datagram destined to the VRRP IPv4 multicast address 224.0.0.18 regardless of its TTL, and likewise MUST NOT forward datagrams to the IPv6 VRRP multicast address FF02:0:0:0:0:0:0:12.

routing, multicast, ip

normative-requirement §8.1.2 MUST

The Virtual Router Master MUST respond to ARP requests (IPv4) or ND Neighbor Solicitation messages (IPv6) with the virtual MAC address, and MUST NOT use its physical MAC address in these responses.

routing, ip

normative-requirement §5.2.8 MUST

The VRRP checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message plus the IPv6-style pseudo-header (RFC 2460 Section 8.1) with Next Header set to 112.

routing

normative-requirement §6.4.3 MUST

Upon shutdown, the Master MUST send an ADVERTISEMENT with Priority=0 before transitioning to Initialize, allowing Backup routers to quickly assume Master role without waiting for the Master_Down_Timer to expire.

routing

normative-requirement §8.4.2 MUST

When configured for VRRPv2 compatibility and acting as Master, a VRRPv3 router MUST send both VRRPv2 and VRRPv3 advertisements at the configured rate, even if sub-second.

routing

normative-requirement §6.4.2 MUST NOT

While in the Backup state, a router MUST NOT respond to ARP requests (IPv4) or ND Neighbor Solicitations (IPv6) for virtual router addresses, MUST NOT send ND Router Advertisements, and MUST discard packets with a destination link-layer MAC equal to the virtual router MAC address.

routing, ip

protocol-element §6.1

Accept_Mode controls whether a Master router (that is not the address owner) accepts packets addressed to the address owner's IPvX address. Default is False. When False, IPv6 Neighbor Solicitations and Neighbor Advertisements MUST NOT be dropped.

routing, ip

protocol-element §5.2.7

Max Adver Int is a 12-bit field indicating the time interval between ADVERTISEMENTS in centiseconds; default is 100 centiseconds (1 second). Sub-second intervals are supported and enable rapid failover.

routing

protocol-element §6.1

Skew_Time is computed as ((256 − priority) × Master_Adver_Interval) / 256 centiseconds. Master_Down_Interval is (3 × Master_Adver_Interval) + Skew_Time, ensuring higher-priority Backups time out sooner and win elections.

routing

protocol-element §5.2.4

The Priority field (8-bit unsigned integer) specifies the VRRP router's election priority. Value 255 is reserved for the IPvX address owner; values 1–254 are for Backup routers (default 100); value 0 signals that the current Master is releasing responsibility, triggering rapid Backup-to-Master transition.

routing

protocol-element §7.3

The virtual router MAC address for IPv4 is 00-00-5E-00-01-{VRID} and for IPv6 is 00-00-5E-00-02-{VRID} in Internet-standard bit-order. This mapping provides for up to 255 VRRP routers per address family on a network.

routing, ip

registry §11

IANA assigned IPv6 link-local scope multicast address FF02:0:0:0:0:0:0:12 for VRRP, and reserved the IEEE 802 MAC address block 00-00-5E-00-02-00 through 00-00-5E-00-02-FF for VRRP for IPv6. The IPv4 MAC block 00-00-5E-00-01-00 through 00-00-5E-00-01-FF and IPv4 multicast address 224.0.0.18 were previously assigned.

routing, registry, ip

security-consideration §9

The TTL/Hop Limit = 255 mechanism protects against VRRP packets being injected from remote networks, restricting most attack vectors to locally attached nodes. VRRP itself does not add new attack vectors beyond what any LAN-attached node can do via ARP/ND spoofing.

routing, security

security-consideration §9

VRRP provides no confidentiality, which is acceptable since VRRP messages contain no information requiring secrecy. For IPv6 deployments, VRRP is compatible with SEND 'trust anchor' and 'trust anchor or cga' modes, requiring Master and Backup to share the same prefix delegation in certificates.

routing, security

security-consideration §9

VRRPv3 includes no authentication. Authentication was present in earlier versions but removed because it could not prevent hostile nodes from acting as a VRRP Master and creating multiple Masters, which is as disruptive as having no Master. The TTL=255 check limits attacks to local network nodes.

routing, security

state-machine §6.3

VRRP defines three states per virtual router: Initialize (awaiting Startup event), Backup (monitoring Master availability via Master_Down_Timer), and Master (forwarding packets and sending periodic ADVERTISEMENTs). The IP address owner transitions Initialize→Master immediately; others go Initialize→Backup. Master_Down_Timer expiry triggers Backup→Master.

routing

wire-format §5.1

The VRRP packet header contains: Version (4 bits), Type (4 bits), Virtual Rtr ID (8 bits), Priority (8 bits), Count IPvX Addr (8 bits), Rsvd (4 bits), Max Adver Int (12 bits), Checksum (16 bits), followed by one or more IPvX addresses. The packet is encapsulated in IPv4 or IPv6 with protocol/Next Header 112.

routing, ip