summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5798.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5798.txt')
-rw-r--r--doc/rfc/rfc5798.txt2243
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc5798.txt b/doc/rfc/rfc5798.txt
new file mode 100644
index 0000000..adc0383
--- /dev/null
+++ b/doc/rfc/rfc5798.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Nadas, Ed.
+Request for Comments: 5798 Ericsson
+Obsoletes: 3768 March 2010
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
+
+Abstract
+
+ 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5798.
+
+
+
+
+
+Nadas Standards Track [Page 1]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. A Note on Terminology ......................................4
+ 1.2. IPv4 .......................................................5
+ 1.3. IPv6 .......................................................6
+ 1.4. Requirements Language ......................................6
+ 1.5. Scope ......................................................7
+ 1.6. Definitions ................................................7
+ 2. Required Features ...............................................8
+ 2.1. IPvX Address Backup ........................................8
+ 2.2. Preferred Path Indication ..................................8
+ 2.3. Minimization of Unnecessary Service Disruptions ............9
+ 2.4. Efficient Operation over Extended LANs .....................9
+ 2.5. Sub-Second Operation for IPv4 and IPv6 .....................9
+ 3. VRRP Overview ..................................................10
+ 4. Sample Configurations ..........................................11
+ 4.1. Sample Configuration 1 ....................................11
+ 4.2. Sample Configuration 2 ....................................13
+
+
+
+
+
+Nadas Standards Track [Page 2]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ 5. Protocol .......................................................14
+ 5.1. VRRP Packet Format ........................................15
+ 5.1.1. IPv4 Field Descriptions ............................15
+ 5.1.1.1. Source Address ............................15
+ 5.1.1.2. Destination Address .......................15
+ 5.1.1.3. TTL .......................................16
+ 5.1.1.4. Protocol ..................................16
+ 5.1.2. IPv6 Field Descriptions ............................16
+ 5.1.2.1. Source Address ............................16
+ 5.1.2.2. Destination Address .......................16
+ 5.1.2.3. Hop Limit .................................16
+ 5.1.2.4. Next Header ...............................16
+ 5.2. VRRP Field Descriptions ...................................16
+ 5.2.1. Version ............................................16
+ 5.2.2. Type ...............................................17
+ 5.2.3. Virtual Rtr ID (VRID) ..............................17
+ 5.2.4. Priority ...........................................17
+ 5.2.5. Count IPvX Addr ....................................17
+ 5.2.6. Rsvd ...............................................17
+ 5.2.7. Maximum Advertisement Interval (Max Adver Int) .....17
+ 5.2.8. Checksum ...........................................18
+ 5.2.9. IPvX Address(es) ...................................18
+ 6. Protocol State Machine .........................................18
+ 6.1. Parameters Per Virtual Router .............................18
+ 6.2. Timers ....................................................20
+ 6.3. State Transition Diagram ..................................21
+ 6.4. State Descriptions ........................................21
+ 6.4.1. Initialize .........................................21
+ 6.4.2. Backup .............................................22
+ 6.4.3. Master .............................................24
+ 7. Sending and Receiving VRRP Packets .............................26
+ 7.1. Receiving VRRP Packets ....................................26
+ 7.2. Transmitting VRRP Packets .................................27
+ 7.3. Virtual Router MAC Address ................................28
+ 7.4. IPv6 Interface Identifiers ................................28
+ 8. Operational Issues .............................................29
+ 8.1. IPv4 ......................................................29
+ 8.1.1. ICMP Redirects .....................................29
+ 8.1.2. Host ARP Requests ..................................29
+ 8.1.3. Proxy ARP ..........................................30
+ 8.2. IPv6 ......................................................30
+ 8.2.1. ICMPv6 Redirects ...................................30
+ 8.2.2. ND Neighbor Solicitation ...........................30
+ 8.2.3. Router Advertisements ..............................31
+ 8.3. IPvX ......................................................31
+ 8.3.1. Potential Forwarding Loop ..........................31
+ 8.3.2. Recommendations Regarding Setting Priority Values ..32
+
+
+
+
+Nadas Standards Track [Page 3]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ 8.4. VRRPv3 and VRRPv2 Interoperation ..........................32
+ 8.4.1. Assumptions ........................................32
+ 8.4.2. VRRPv3 Support of VRRPv2 ...........................32
+ 8.4.3. VRRPv3 Support of VRRPv2 Considerations ............33
+ 8.4.3.1. Slow, High-Priority Masters ...............33
+ 8.4.3.2. Overwhelming VRRPv2 Backups ...............33
+ 9. Security Considerations ........................................33
+ 10. Contributors and Acknowledgments ..............................34
+ 11. IANA Considerations ...........................................35
+ 12. References ....................................................35
+ 12.1. Normative References .....................................35
+ 12.2. Informative References ...................................36
+ Appendix A. Operation over FDDI, Token Ring, and ATM LANE .........38
+ A.1. Operation over FDDI .......................................38
+ A.2. Operation over Token Ring .................................38
+ A.3. Operation over ATM LANE ...................................40
+
+1. Introduction
+
+ This memo defines the Virtual Router Redundancy Protocol (VRRP) for
+ IPv4 and IPv6. It is version three (3) of the protocol. It is based
+ on VRRP (version 2) for IPv4 that is defined in [RFC3768] and in
+ [VRRP-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.
+
+ VRRP provides a function similar to the proprietary protocols "Hot
+ Standby Router Protocol (HSRP)" [RFC2281] and "IP Standby Protocol"
+ [IPSTB].
+
+1.1. A Note on Terminology
+
+ This document discusses both IPv4 and IPv6 operation, 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" usually 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
+
+
+
+Nadas Standards Track [Page 4]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ matters, the appropriate term is used and the use of the term "IP" is
+ avoided.
+
+1.2. IPv4
+
+ There are a number of methods that an IPv4 end-host can use to
+ determine its first-hop router towards a particular IPv4 destination.
+ These include running (or snooping) a dynamic routing protocol such
+ as Routing Information Protocol [RFC2453] or OSPF version 2
+ [RFC2328], running an ICMP router discovery client [RFC1256], or
+ using a statically configured default route.
+
+ Running a dynamic routing protocol on every end-host may be
+ infeasible for a number of reasons, including administrative
+ overhead, processing overhead, security issues, or lack of a protocol
+ implementation for some platforms. Neighbor or router discovery
+ protocols may require active participation by all hosts on a network,
+ leading to large timer values to reduce protocol overhead in the face
+ of large numbers of hosts. This can result in a significant delay in
+ the detection of a lost (i.e., dead) neighbor; such a delay may
+ introduce unacceptably long "black hole" periods.
+
+ The use of a statically configured default route is quite popular; it
+ minimizes configuration and processing overhead on the end-host and
+ is supported by virtually every IPv4 implementation. This mode of
+ operation is likely to persist as dynamic host configuration
+ protocols [RFC2131] are deployed, which typically provide
+ configuration for an end-host IPv4 address and default gateway.
+ 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 any alternate path that may be available.
+
+ The Virtual Router Redundancy Protocol (VRRP) is designed to
+ eliminate the single point of failure inherent in the static default-
+ routed environment. 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 Master and
+ forwards packets sent to these IPv4 addresses. The election process
+ provides dynamic failover in the forwarding responsibility should the
+ Master become unavailable. Any of the virtual router's IPv4
+ addresses on a LAN can then be used as the default first hop
+
+
+
+
+
+
+
+
+
+Nadas Standards Track [Page 5]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ router by end-hosts. The advantage gained from using VRRP is a
+ higher availability default path without requiring configuration of
+ dynamic routing or router discovery protocols on every end-host.
+
+1.3. IPv6
+
+ IPv6 hosts on a LAN will usually learn about one or more default
+ routers by receiving Router Advertisements sent using the IPv6
+ Neighbor Discovery (ND) protocol [RFC4861]. The Router
+ Advertisements are multicast periodically at a rate that the hosts
+ will learn about the default routers in a few minutes. They are not
+ sent frequently enough to rely on the absence of the Router
+ Advertisement to detect router failures.
+
+ Neighbor Discovery (ND) 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 will take a host about 38 seconds to learn that a router is
+ unreachable before it will switch to another default router. This
+ delay would be very noticeable to users and cause some transport
+ protocol implementations to time out.
+
+ While the ND unreachability detection could be made quicker by
+ changing the parameters 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
+ of more routers.
+
+ The Virtual Router Redundancy Protocol for IPv6 provides a much
+ faster switchover to an alternate default router than can be obtained
+ using standard ND procedures. Using VRRP, a Backup router can take
+ over for a failed default router in around three seconds (using VRRP
+ default parameters). This is done without any interaction with the
+ hosts and a minimum amount of VRRP traffic.
+
+1.4. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+Nadas Standards Track [Page 6]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+1.5. Scope
+
+ The remainder of this document describes the features, design goals,
+ and theory of operation of VRRP. The message formats, protocol
+ processing rules, and state machine that guarantee convergence to a
+ single Virtual Router Master are presented. Finally, operational
+ issues related to MAC address mapping, handling of ARP requests,
+ generation of ICMP redirect messages, and security issues are
+ addressed.
+
+1.6. Definitions
+
+ VRRP Router A router running the Virtual Router
+ Redundancy Protocol. It may participate as
+ one or more virtual routers.
+
+ Virtual Router An abstract object managed by VRRP that acts
+ as a default router for hosts on a shared
+ LAN. It consists of a Virtual Router
+ Identifier and either a set of associated
+ IPv4 addresses or a set of associated IPv6
+ addresses across a common LAN. A VRRP Router
+ may back up one or more virtual routers.
+
+ IP Address Owner The VRRP router that has the virtual router's
+ IPvX address(es) as real interface
+ address(es). This is the router that, when
+ up, will respond to packets addressed to one
+ of these IPvX addresses for ICMP pings, TCP
+ connections, etc.
+
+ Primary IP Address In IPv4, an IPv4 address selected from the
+ set of real interface addresses. One
+ possible selection algorithm is to always
+ select the first address. In IPv4 mode, 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.
+
+ Virtual Router Master 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
+
+
+
+
+
+
+Nadas Standards Track [Page 7]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ 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 become the Master.
+
+ Virtual Router Backup The set of VRRP routers available to assume
+ forwarding responsibility for a virtual
+ router should the current Master fail.
+
+2. Required Features
+
+ This section outlines the set of features that were considered
+ mandatory and that guided the design of VRRP.
+
+2.1. IPvX Address Backup
+
+ Backup of an IPvX address or addresses is the primary function of
+ VRRP. While providing election of a Virtual Router Master and the
+ additional functionality described below, the protocol should
+ strive to:
+
+ o Minimize the duration of black holes.
+
+ o Minimize the steady-state bandwidth overhead and processing
+ complexity.
+
+ o Function over a wide variety of multiaccess LAN technologies
+ capable of supporting IPvX traffic.
+
+ o Allow multiple virtual routers on a network for load balancing.
+
+ o Support multiple logical IPvX subnets on a single LAN segment.
+
+2.2. Preferred Path Indication
+
+ A simple model of Master election among a set of redundant routers is
+ to treat each router with equal preference and claim victory after
+ converging to any router as Master. 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 Master convergence to the most
+ preferential router currently available.
+
+
+
+
+
+
+Nadas Standards Track [Page 8]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+2.3. Minimization of Unnecessary Service Disruptions
+
+ Once Master election has been performed, any unnecessary transitions
+ between Master and Backup routers can result in a disruption in
+ service. The protocol should ensure after Master election that no
+ state transition is triggered by any Backup router of equal or lower
+ preference as long as the Master continues to function properly.
+
+ Some environments may find it beneficial to avoid the state
+ transition triggered when a router that is preferred over the current
+ Master becomes available. It may be useful to support an override of
+ the immediate convergence to the preferred path.
+
+2.4. Efficient Operation over Extended LANs
+
+ Sending IPvX packets (that is, 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 station 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:
+ 1) use the virtual router MAC address as the source in a packet sent
+ by the Master to trigger station learning; 2) trigger a message
+ immediately after transitioning to the Master to update the station
+ learning; and 3) trigger periodic messages from the Master to
+ maintain the station learning cache.
+
+2.5. Sub-Second Operation for IPv4 and IPv6
+
+ Sub-second detection of Master VRRP router failure is needed in both
+ IPv4 and IPv6 environments. Earlier work proposed that sub-second
+ operation was for IPv6; this specification leverages that earlier
+ approach for IPv4 and IPv6.
+
+ One possible problematic scenario when using small
+ VRRP_Advertisement_Intervals may occur when a router is delivering
+ more packets onto the LAN than can be accommodated, and so a queue
+ builds up in the router. It is possible that packets being
+ transmitted onto the VRRP-protected LAN could see larger queueing
+ delay than the smallest VRRP Advertisement_Interval. In this case,
+ the Master_Down_Interval will be small enough so that normal queuing
+ delays might cause a VRRP Backup to conclude that the Master is down,
+ and therefore promote itself to Master. Very shortly afterwards, the
+ delayed VRRP packets from the Master cause a switch back to Backup
+ status. Furthermore, this process can repeat many times per second,
+
+
+
+Nadas Standards Track [Page 9]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ causing significant disruption to traffic. To mitigate this problem,
+ priority forwarding of VRRP packets should be considered. It should
+ be possible for a VRRP Master to observe that this situation is
+ occurring frequently and at least log the problem.
+
+3. VRRP Overview
+
+ VRRP specifies an election protocol to provide the virtual router
+ function described earlier. All protocol messaging is performed
+ using either IPv4 or IPv6 multicast datagrams; thus, the protocol can
+ operate over a variety of multiaccess LAN technologies supporting
+ IPvX multicast. Each link of a VRRP virtual router has a single
+ well-known MAC address allocated to it. This document currently only
+ details the mapping to networks using the IEEE 802 48-bit MAC
+ address. The virtual router MAC address is used as the source in all
+ periodic VRRP messages sent by the Master router to enable bridge
+ learning in an extended LAN.
+
+ A virtual router is defined by its virtual router identifier (VRID)
+ and a set of either IPv4 or IPv6 address(es). A VRRP router may
+ associate a virtual router with its real address on an interface.
+ The scope of each virtual router is restricted to a single LAN. A
+ VRRP router may be configured with additional virtual router mappings
+ and priority for virtual routers it is willing to back up. The
+ mapping between the VRID and its IPvX address(es) must be coordinated
+ among all VRRP routers on a LAN.
+
+ There is no restriction against reusing a VRID with a different
+ address mapping on different LANs, nor is there a restriction against
+ using the same VRID number for a set of IPv4 addresses and a set of
+ IPv6 addresses; however, these are two different virtual routers.
+
+ To minimize network traffic, only the Master for each virtual router
+ sends periodic VRRP Advertisement messages. A Backup router will not
+ attempt to preempt the Master unless it has higher priority. This
+ eliminates service disruption unless a more preferred path becomes
+ available. It's also possible to administratively prohibit all
+ preemption attempts. The only exception is that a VRRP router will
+ always become Master of any virtual router associated with addresses
+ it owns. If the Master becomes unavailable, then the highest-
+ priority Backup will transition to Master after a short delay,
+ providing a controlled transition of the virtual router
+ responsibility with minimal service interruption.
+
+ The VRRP protocol design provides rapid transition from Backup to
+ Master to minimize service interruption and incorporates
+ optimizations that reduce protocol complexity while guaranteeing
+
+
+
+
+Nadas Standards Track [Page 10]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ controlled Master transition for typical operational scenarios. The
+ 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
+ among each router. A side effect when these assumptions are violated
+ (i.e., more than two redundant paths, all with equal preference) is
+ that duplicate packets may be forwarded for a brief period during
+ Master election. However, the typical scenario assumptions are
+ likely to cover the vast majority of deployments, loss of the Master
+ router is infrequent, and the expected duration in Master election
+ convergence is quite small ( << 1 second ). Thus, the VRRP
+ optimizations represent significant simplifications in the protocol
+ design while incurring an insignificant probability of brief network
+ degradation.
+
+4. Sample Configurations
+
+4.1. Sample Configuration 1
+
+ The following figure shows a simple network with two VRRP routers
+ implementing one virtual router.
+
+ +-----------+ +-----------+
+ | Rtr1 | | Rtr2 |
+ |(MR VRID=1)| |(BR VRID=1)|
+ | | | |
+VRID=1 +-----------+ +-----------+
+IPvX A--------->* *<---------IPvX B
+ | |
+ | |
+----------------+------------+-----+----------+----------+----------+--
+ ^ ^ ^ ^
+ | | | |
+default rtr IPvX addrs-------> (IPvX A) (IPvX A) (IPvX A) (IPvX A)
+ | | | |
+ IPvX H1->* IpvX H2->* IPvX H3->* IpvX H4->*
+ +--+--+ +--+--+ +--+--+ +--+--+
+ | H1 | | H2 | | H3 | | H4 |
+ +-----+ +-----+ +--+--+ +--+--+
+ Legend:
+ --+---+---+-- = Ethernet, Token Ring, or FDDI
+ H = Host computer
+ MR = Master 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
+
+
+
+Nadas Standards Track [Page 11]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ Eliminating all mention of VRRP (VRID=1) from the figure above leaves
+ it as a typical deployment.
+
+ In the IPv4 case (that is, IPvX is IPv4 everywhere in the figure),
+ each router is permanently assigned an IPv4 address on the LAN
+ interface (Rtr1 is assigned IPv4 A and Rtr2 is assigned IPv4 B), and
+ each host installs a static default route through one of the routers
+ (in this example they all use Rtr1's IPv4 A).
+
+ In the IPv6 case (that is, IPvX is IPv6 everywhere in the figure),
+ each router has a link-local IPv6 address on the LAN interface (Rtr1
+ is assigned IPv6 Link-Local A and Rtr2 is assigned IPv6 Link-
+ Local B), and each host learns a default route from Router
+ Advertisements through one of the routers (in this example, they all
+ use Rtr1's IPv6 Link-Local A).
+
+ Moving to an IPv4 VRRP environment, each router has the exact same
+ permanently assigned IPv4 address. Rtr1 is said to be the IPv4
+ address owner of IPv4 A, and Rtr2 is the IPv4 address owner of
+ IPv4 B. A virtual router is then defined by associating a unique
+ identifier (the virtual router ID) with the address owned by a
+ router.
+
+ Moving to an IPv6 VRRP environment, each router has the exact same
+ Link-Local IPv6 address. Rtr1 is said to be the IPv6 address owner
+ of IPv6 A, and Rtr2 is the IPv6 address owner of IPv6 B. A virtual
+ router is then defined by associating a unique identifier (the
+ virtual router ID) with the address owned by a router.
+
+ Finally, in both the IPv4 and IPv6 cases, the VRRP protocol manages
+ virtual router failover to a Backup router.
+
+ The IPv4 example above shows a virtual router configured to cover the
+ IPv4 address owned by Rtr1 (VRID=1, IPv4_Address=A). When VRRP is
+ enabled on Rtr1 for VRID=1, it will assert itself as Master, with
+ priority = 255, since it is the IP address owner for the virtual
+ router IP address. When VRRP is enabled on Rtr2 for VRID=1, it will
+ transition to Backup, with priority = 100 (the default priority is
+ 100), since it is not the IPv4 address owner. If Rtr1 should fail,
+ then the VRRP protocol will transition Rtr2 to Master, temporarily
+ taking over forwarding responsibility for IPv4 A to provide
+ uninterrupted service to the hosts. When Rtr1 returns to service, it
+ will re-assert itself as Master.
+
+ The IPv6 example above shows a virtual router configured to cover the
+ IPv6 address owned by Rtr1 (VRID=1, IPv6_Address=A). When VRRP is
+ enabled on Rtr1 for VRID=1, it will assert itself as Master, with
+ priority = 255, since it is the IPv6 address owner for the virtual
+
+
+
+Nadas Standards Track [Page 12]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ router IPv6 address. When VRRP is enabled on Rtr2 for VRID=1, it
+ will transition to Backup, with priority = 100 (the default priority
+ is 100), since it is not the IPv6 address owner. If Rtr1 should
+ fail, then the VRRP protocol will transition Rtr2 to Master,
+ temporarily taking over forwarding responsibility for IPv6 A to
+ provide uninterrupted service to the hosts.
+
+ Note that in both cases, in this example IPvX B is not backed up; it
+ is only used by Rtr2 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.
+
+4.2. Sample Configuration 2
+
+ The following figure shows a configuration with two virtual routers
+ with the hosts splitting their traffic between them.
+
+ +-----------+ +-----------+
+ | Rtr1 | | Rtr2 |
+ |(MR VRID=1)| |(BR VRID=1)|
+ |(BR VRID=2)| |(MR VRID=2)|
+VRID=1 +-----------+ +-----------+ VRID=2
+IPvX A -------->* *<---------- IPvX B
+ | |
+ | |
+----------------+------------+-----+----------+----------+----------+--
+ ^ ^ ^ ^
+ | | | |
+default rtr IPvX addrs -----> (IPvX A) (IPvX A) (IPvX B) (IPvX B)
+ | | | |
+ IPvX H1->* IpvX H2->* IPvX H3->* IpvX H4->*
+ +--+--+ +--+--+ +--+--+ +--+--+
+ | H1 | | H2 | | H3 | | H4 |
+ +-----+ +-----+ +--+--+ +--+--+
+ Legend:
+ ---+---+---+-- = Ethernet, Token Ring, or FDDI
+ H = Host computer
+ MR = Master Router
+ BR = Backup Router
+ * = IPvX Address; X is 4 everywhere in IPv4 case
+ X is 6 everywhere in IPv6 case
+ (IPvX) = default router for hosts
+
+ In the IPv4 example above (that is, IPvX is IPv4 everywhere in the
+ figure), half of the hosts have configured a static route through
+ Rtr1's IPv4 A, and half are using Rtr2's IPv4 B. The configuration
+ of virtual router VRID=1 is exactly the same as in the first example
+ (see Section 4.1), and a second virtual router has been added to
+
+
+
+Nadas Standards Track [Page 13]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ cover the IPv4 address owned by Rtr2 (VRID=2, IPv4_Address=B). In
+ this case, Rtr2 will assert itself as Master for VRID=2 while Rtr1
+ will act as a Backup. This scenario demonstrates a deployment
+ providing load splitting when both routers are available, while
+ providing full redundancy for robustness.
+
+ In the IPv6 example above (that is, IPvX is IPv6 everywhere in the
+ figure), half of the hosts have learned a default route through
+ Rtr1's IPv6 A, and half are using Rtr2's IPv6 B. The configuration
+ of virtual router VRID=1 is exactly the same as in the first example
+ (see Section 4.1), and a second virtual router has been added to
+ cover the IPv6 address owned by Rtr2 (VRID=2, IPv6_Address=B). In
+ this case, Rtr2 will assert itself as Master for VRID=2 while Rtr1
+ will act as a Backup. This scenario demonstrates a deployment
+ providing load splitting when both routers are available, while
+ providing full redundancy for robustness.
+
+ Note that the details of load balancing are out of scope of this
+ document. However, in a case where the servers need different
+ weights, it may not make sense to rely on router advertisements alone
+ to balance the host load between the routers.
+
+5. Protocol
+
+ The purpose of the VRRP packet is to communicate to all VRRP routers
+ the priority and the state of the Master router associated with the
+ VRID.
+
+ When VRRP is protecting an IPv4 address, VRRP packets are sent
+ encapsulated in IPv4 packets. They are sent to the IPv4 multicast
+ address assigned to VRRP.
+
+ When VRRP is protecting an IPv6 address, VRRP packets are sent
+ encapsulated in IPv6 packets. They are sent to the IPv6 multicast
+ address assigned to VRRP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadas Standards Track [Page 14]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+5.1. VRRP Packet Format
+
+ This section defines the format of the VRRP packet and the relevant
+ fields in the IP header.
+
+ 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 |Count IPvX Addr|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |(rsvd) | Max Adver Int | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | IPvX Address(es) |
+ + +
+ + +
+ + +
+ + +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.1.1. IPv4 Field Descriptions
+
+5.1.1.1. Source Address
+
+ This is the primary IPv4 address of the interface the packet is being
+ sent from.
+
+5.1.1.2. Destination Address
+
+ The IPv4 multicast address as assigned by the IANA for VRRP is:
+
+ 224.0.0.18
+
+ This is a link-local scope multicast address. Routers MUST NOT
+ forward a datagram with this destination address, regardless of its
+ TTL.
+
+
+
+
+
+
+
+Nadas Standards Track [Page 15]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+5.1.1.3. TTL
+
+ The TTL MUST be set to 255. A VRRP router receiving a packet with
+ the TTL not equal to 255 MUST discard the packet.
+
+5.1.1.4. Protocol
+
+ The IPv4 protocol number assigned by the IANA for VRRP is 112
+ (decimal).
+
+5.1.2. IPv6 Field Descriptions
+
+5.1.2.1. Source Address
+
+ This is the IPv6 link-local address of the interface the packet is
+ being sent from.
+
+5.1.2.2. Destination Address
+
+ The IPv6 multicast address assigned by the IANA for VRRP is:
+
+ FF02:0:0:0:0:0:0:12
+
+ This is a link-local scope multicast address. Routers MUST NOT
+ forward a datagram with this destination address, regardless of its
+ Hop Limit.
+
+5.1.2.3. Hop Limit
+
+ The Hop Limit MUST be set to 255. A VRRP router receiving a packet
+ with the Hop Limit not equal to 255 MUST discard the packet.
+
+5.1.2.4. Next Header
+
+ The IPv6 Next Header protocol assigned by the IANA for VRRP is 112
+ (decimal).
+
+5.2. VRRP Field Descriptions
+
+5.2.1. Version
+
+ The version field specifies the VRRP protocol version of this packet.
+ This document defines version 3.
+
+
+
+
+
+
+
+
+Nadas Standards Track [Page 16]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+5.2.2. Type
+
+ The type field specifies the type of this VRRP packet. The only
+ packet type defined in this version of the protocol is:
+
+ 1 ADVERTISEMENT
+
+ A packet with unknown type MUST be discarded.
+
+5.2.3. Virtual Rtr ID (VRID)
+
+ The Virtual Rtr ID field identifies the virtual router this packet is
+ reporting status for.
+
+5.2.4. Priority
+
+ The priority field specifies the sending VRRP router's priority for
+ the virtual router. Higher values equal higher priority. This field
+ is an 8-bit unsigned integer field.
+
+ The priority value for the VRRP router that owns the IPvX address
+ associated with the virtual router MUST be 255 (decimal).
+
+ VRRP routers backing up a virtual router MUST use priority values
+ between 1-254 (decimal). The default priority value for VRRP routers
+ backing up a virtual router is 100 (decimal).
+
+ The priority value zero (0) has special meaning, indicating that the
+ current Master has stopped participating in VRRP. This is used to
+ trigger Backup routers to quickly transition to Master without having
+ to wait for the current Master to time out.
+
+5.2.5. Count IPvX Addr
+
+ This is the number of either IPv4 addresses or IPv6 addresses
+ contained in this VRRP advertisement. The minimum value is 1.
+
+5.2.6. Rsvd
+
+ This field MUST be set to zero on transmission and ignored on
+ reception.
+
+5.2.7. Maximum Advertisement Interval (Max Adver Int)
+
+ The Maximum Advertisement Interval is a 12-bit field that indicates
+ the time interval (in centiseconds) between ADVERTISEMENTS. The
+ default is 100 centiseconds (1 second).
+
+
+
+
+Nadas Standards Track [Page 17]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ Note that higher-priority Master routers with slower transmission
+ rates than their Backup routers are unstable. This is because low-
+ priority nodes configured to faster rates could come online and
+ decide they should be Masters before they have heard anything from
+ the higher-priority Master with a slower rate. When this happens, it
+ is temporary: once the lower-priority node does hear from the higher-
+ priority Master, it will relinquish mastership.
+
+5.2.8. Checksum
+
+ The checksum field is used to detect data corruption in the VRRP
+ message.
+
+ The checksum is the 16-bit one's complement of the one's complement
+ sum of the entire VRRP message starting with the version field and a
+ "pseudo-header" as defined in Section 8.1 of [RFC2460]. The next
+ header field in the "pseudo-header" should be set to 112 (decimal)
+ for VRRP. For computing the checksum, the checksum field is set to
+ zero. See RFC1071 for more detail [RFC1071].
+
+5.2.9. IPvX Address(es)
+
+ This refers to one or more IPvX addresses associated with the virtual
+ router. The number of addresses included is specified in the "Count
+ IP Addr" 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 make it easier to do this comparison.
+
+ For IPv4 addresses, this refers to one or more IPv4 addresses that
+ are backed up by the virtual router.
+
+ For IPv6, the first address must be the IPv6 link-local address
+ associated with the virtual router.
+
+ This field contains either one or more IPv4 addresses, or one or more
+ IPv6 addresses, that is, IPv4 and IPv6 MUST NOT both be carried in
+ one IPvX Address field.
+
+6. Protocol State Machine
+
+6.1. Parameters Per Virtual Router
+
+ VRID Virtual Router Identifier. Configurable
+ item in the range 1-255 (decimal). There
+ is no default.
+
+
+
+
+
+Nadas Standards Track [Page 18]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ Priority Priority value to be used by this VRRP
+ router in Master 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 Master router to
+ indicate it is releasing responsibility
+ for the virtual router. The range 1-254
+ (decimal) is available for VRRP routers
+ backing up the virtual router. Higher
+ values indicate higher priorities. The
+ default value is 100 (decimal).
+
+ IPv4_Addresses One or more IPv4 addresses associated
+ with this virtual router. Configured
+ item with no default.
+
+ IPv6_Addresses One or more IPv6 addresses associated
+ with this virtual router. Configured
+ item with no default. The first address
+ must be the Link-Local address associated
+ with the virtual router.
+
+ Advertisement_Interval Time interval between ADVERTISEMENTS
+ (centiseconds). Default is 100
+ centiseconds (1 second).
+
+ Master_Adver_Interval Advertisement interval contained in
+ ADVERTISEMENTS received from the Master
+ (centiseconds). This value is saved by
+ virtual routers in the Backup state and
+ used to compute Skew_Time and
+ Master_Down_Interval. The initial value
+ is the same as Advertisement_Interval.
+
+ Skew_Time Time to skew Master_Down_Interval in
+ centiseconds. Calculated as
+
+ (((256 - priority) * Master_Adver_Interval) / 256)
+
+ Master_Down_Interval Time interval for Backup to declare
+ Master down (centiseconds).
+ Calculated as
+
+ (3 * Master_Adver_Interval) + Skew_time
+
+
+
+
+
+Nadas Standards Track [Page 19]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ Preempt_Mode Controls whether a (starting or
+ restarting) higher-priority Backup router
+ preempts a lower-priority Master router.
+ Values are True to allow preemption and
+ False to prohibit preemption. Default is
+ True.
+
+ Note: The exception is that the router
+ that owns the IPvX address associated
+ with the virtual router always preempts,
+ independent of the setting of this flag.
+
+ Accept_Mode Controls whether a virtual router in
+ Master state will accept packets
+ addressed to the address owner's IPvX
+ address as its own if it is not the IPvX
+ address owner. The default is False.
+ Deployments that rely on, for example,
+ pinging the address owner's IPvX address
+ may wish to configure Accept_Mode to
+ True.
+
+ Note: IPv6 Neighbor Solicitations and
+ Neighbor Advertisements MUST NOT be
+ dropped when Accept_Mode is False.
+
+ Virtual_Router_MAC_Address The MAC address used for the source MAC
+ address in VRRP advertisements and
+ advertised in ARP responses as the MAC
+ address to use for IP_Addresses.
+
+6.2. Timers
+
+ Master_Down_Timer Timer that fires when ADVERTISEMENT has not
+ been heard for Master_Down_Interval.
+
+ Adver_Timer Timer that fires to trigger sending of
+ ADVERTISEMENT based on
+ Advertisement_Interval.
+
+
+
+
+
+
+
+
+
+
+
+
+Nadas Standards Track [Page 20]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+6.3. State Transition Diagram
+
+ +---------------+
+ +--------->| |<-------------+
+ | | Initialize | |
+ | +------| |----------+ |
+ | | +---------------+ | |
+ | | | |
+ | V V |
+ +---------------+ +---------------+
+ | |---------------------->| |
+ | Master | | Backup |
+ | |<----------------------| |
+ +---------------+ +---------------+
+
+6.4. State Descriptions
+
+ In the state descriptions below, the state names are identified by
+ {state-name}, and the packets are identified by all-uppercase
+ characters.
+
+ A VRRP router implements an instance of the state machine for each
+ virtual router election it is participating in.
+
+6.4.1. Initialize
+
+ The purpose of this state is to wait for a Startup event, that is, an
+ implementation-defined mechanism that initiates the protocol once it
+ has been configured. The configuration mechanism is out of scope of
+ this specification.
+
+ (100) If a Startup event is received, then:
+
+ (105) - If the Priority = 255 (i.e., the router owns the IPvX
+ address associated with the virtual router), then:
+
+ (110) + Send an ADVERTISEMENT
+
+ (115) + If the protected IPvX address is an IPv4 address, then:
+
+ (120) * Broadcast a gratuitous ARP request containing the
+ virtual router MAC address for each IP address associated
+ with the virtual router.
+
+ (125) + else // IPv6
+
+ (130) * For each IPv6 address associated with the virtual
+ router, send an unsolicited ND Neighbor Advertisement with
+
+
+
+Nadas Standards Track [Page 21]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ the Router Flag (R) set, the Solicited Flag (S) unset, 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.
+
+ (135) +endif // was protected addr IPv4?
+
+ (140) + Set the Adver_Timer to Advertisement_Interval
+
+ (145) + Transition to the {Master} state
+
+ (150) - else // rtr does not own virt addr
+
+ (155) + Set Master_Adver_Interval to Advertisement_Interval
+
+ (160) + Set the Master_Down_Timer to Master_Down_Interval
+
+ (165) + Transition to the {Backup} state
+
+ (170) -endif // priority was not 255
+
+ (175) endif // startup event was recv
+
+6.4.2. Backup
+
+ The purpose of the {Backup} state is to monitor the availability and
+ state of the Master router.
+
+ (300) While in this state, a VRRP router MUST do the following:
+
+ (305) - If the protected IPvX address is an IPv4 address, then:
+
+ (310) + MUST NOT respond to ARP requests for the IPv4
+ address(es) associated with the virtual router.
+
+ (315) - else // protected addr is IPv6
+
+ (320) + MUST NOT respond to ND Neighbor Solicitation messages
+ for the IPv6 address(es) associated with the virtual router.
+
+ (325) + MUST NOT send ND Router Advertisement messages for the
+ virtual router.
+
+ (330) -endif // was protected addr IPv4?
+
+ (335) - MUST discard packets with a destination link-layer MAC
+ address equal to the virtual router MAC address.
+
+
+
+
+Nadas Standards Track [Page 22]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ (340) - MUST NOT accept packets addressed to the IPvX address(es)
+ associated with the virtual router.
+
+ (345) - If a Shutdown event is received, then:
+
+ (350) + Cancel the Master_Down_Timer
+
+ (355) + Transition to the {Initialize} state
+
+ (360) -endif // shutdown recv
+
+ (365) - If the Master_Down_Timer fires, then:
+
+ (370) + Send an ADVERTISEMENT
+
+ (375) + If the protected IPvX address is an IPv4 address, then:
+
+ (380) * Broadcast a gratuitous ARP request on that interface
+ containing the virtual router MAC address for each IPv4
+ address associated with the virtual router.
+
+ (385) + else // ipv6
+
+ (390) * Compute and join the Solicited-Node multicast
+ address [RFC4291] for the IPv6 address(es) associated with
+ the virtual router.
+
+ (395) * 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) unset, 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.
+
+ (400) +endif // was protected addr ipv4?
+
+ (405) + Set the Adver_Timer to Advertisement_Interval
+
+ (410) + Transition to the {Master} state
+
+ (415) -endif // Master_Down_Timer fired
+
+ (420) - If an ADVERTISEMENT is received, then:
+
+ (425) + If the Priority in the ADVERTISEMENT is zero, then:
+
+ (430) * Set the Master_Down_Timer to Skew_Time
+
+
+
+
+Nadas Standards Track [Page 23]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ (440) + else // priority non-zero
+
+ (445) * If Preempt_Mode is False, or if the Priority in the
+ ADVERTISEMENT is greater than or equal to the local
+ Priority, then:
+
+ (450) @ Set Master_Adver_Interval to Adver Interval
+ contained in the ADVERTISEMENT
+
+ (455) @ Recompute the Master_Down_Interval
+
+ (460) @ Reset the Master_Down_Timer to
+ Master_Down_Interval
+
+ (465) * else // preempt was true or priority was less
+
+ (470) @ Discard the ADVERTISEMENT
+
+ (475) *endif // preempt test
+
+ (480) +endif // was priority zero?
+
+ (485) -endif // was advertisement recv?
+
+ (490) endwhile // Backup state
+
+6.4.3. Master
+
+ While in the {Master} state, the router functions as the forwarding
+ router for the IPvX address(es) associated with the virtual router.
+
+ Note that in the Master state, the Preempt_Mode Flag is not
+ considered.
+
+ (600) While in this state, a VRRP router MUST do the following:
+
+ (605) - If the protected IPvX address is an IPv4 address, then:
+
+ (610) + MUST respond to ARP requests for the IPv4 address(es)
+ associated with the virtual router.
+
+ (615) - else // ipv6
+
+ (620) + MUST be a member of the Solicited-Node multicast
+ address for the IPv6 address(es) associated with the virtual
+ router.
+
+
+
+
+
+Nadas Standards Track [Page 24]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ (625) + MUST respond to ND Neighbor Solicitation message for
+ the IPv6 address(es) associated with the virtual router.
+
+ (630) ++ MUST send ND Router Advertisements for the virtual
+ router.
+
+ (635) ++ If Accept_Mode is False: MUST NOT drop IPv6 Neighbor
+ Solicitations and Neighbor Advertisements.
+
+ (640) +-endif // ipv4?
+
+ (645) - MUST forward packets with a destination link-layer MAC
+ address equal to the virtual router MAC address.
+
+ (650) - MUST accept packets addressed to the IPvX address(es)
+ associated with the virtual router if it is the IPvX address owner
+ or if Accept_Mode is True. Otherwise, MUST NOT accept these
+ packets.
+
+ (655) - If a Shutdown event is received, then:
+
+ (660) + Cancel the Adver_Timer
+
+ (665) + Send an ADVERTISEMENT with Priority = 0
+
+ (670) + Transition to the {Initialize} state
+
+ (675) -endif // shutdown recv
+
+ (680) - If the Adver_Timer fires, then:
+
+ (685) + Send an ADVERTISEMENT
+
+ (690) + Reset the Adver_Timer to Advertisement_Interval
+
+ (695) -endif // advertisement timer fired
+
+ (700) - If an ADVERTISEMENT is received, then:
+
+ (705) -+ If the Priority in the ADVERTISEMENT is zero, then:
+
+ (710) -* Send an ADVERTISEMENT
+
+ (715) -* Reset the Adver_Timer to Advertisement_Interval
+
+ (720) -+ else // priority was non-zero
+
+
+
+
+
+Nadas Standards Track [Page 25]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ (725) -* If the Priority in the ADVERTISEMENT is greater
+ than the local Priority,
+
+ (730) -* or
+
+ (735) -* If the Priority in the ADVERTISEMENT is equal to
+ the local Priority and the primary IPvX Address of the
+ sender is greater than the local primary IPvX Address, then:
+
+ (740) -@ Cancel Adver_Timer
+
+ (745) -@ Set Master_Adver_Interval to Adver Interval
+ contained in the ADVERTISEMENT
+
+ (750) -@ Recompute the Skew_Time
+
+ (755) @ Recompute the Master_Down_Interval
+
+ (760) @ Set Master_Down_Timer to Master_Down_Interval
+
+ (765) @ Transition to the {Backup} state
+
+ (770) * else // new Master logic
+
+ (775) @ Discard ADVERTISEMENT
+
+ (780) *endif // new Master detected
+
+ (785) +endif // was priority zero?
+
+ (790) -endif // advert recv
+
+ (795) endwhile // in Master
+
+7. Sending and Receiving VRRP Packets
+
+7.1. Receiving VRRP Packets
+
+ The following functions are performed when a VRRP packet is received:
+
+ - If the received packet is an IPv4 packet, then:
+
+ + MUST verify that the IPv4 TTL is 255.
+
+ - else // ipv6 recv
+
+ + MUST verify that the IPv6 Hop Limit is 255.
+
+
+
+
+Nadas Standards Track [Page 26]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ -endif
+
+ - MUST verify that the VRRP version is 3.
+
+ - MUST verify that the received packet contains the complete VRRP
+ packet (including fixed fields, and IPvX address).
+
+ - MUST verify the VRRP checksum.
+
+ - MUST verify that the VRID is configured on the receiving
+ interface and the local router is not the IPvX address owner
+ (Priority = 255 (decimal)).
+
+ If any one of the above checks fails, the receiver MUST discard the
+ packet, SHOULD log the event, and MAY indicate via network management
+ that an error occurred.
+
+ - MAY verify that "Count IPvX Addrs" and the list of IPvX
+ address(es) match the IPvX Address(es) configured for the VRID.
+
+ If the above check fails, the receiver SHOULD log the event and MAY
+ indicate via network management that a misconfiguration was detected.
+
+7.2. Transmitting VRRP Packets
+
+ The following operations MUST be performed when transmitting a VRRP
+ packet:
+
+ - Fill in the VRRP packet fields with the appropriate virtual
+ router configuration state
+
+ - Compute the VRRP checksum
+
+ - If the protected address is an IPv4 address, then:
+
+ + Set the source MAC address to virtual router MAC Address
+
+ + Set the source IPv4 address to interface primary IPv4 address
+
+ - else // ipv6
+
+ + Set the source MAC address to virtual router MAC Address
+
+ + Set the source IPv6 address to interface link-local IPv6
+ address
+
+ -endif
+
+
+
+
+Nadas Standards Track [Page 27]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ - Set the IPvX protocol to VRRP
+
+ - Send the VRRP packet to the VRRP IPvX multicast group
+
+ Note: VRRP packets are transmitted with the virtual router MAC
+ address as the source MAC address to ensure that learning bridges
+ correctly determine the LAN segment the virtual router is
+ attached to.
+
+7.3. Virtual Router MAC Address
+
+ The virtual router MAC address associated with a virtual router is an
+ IEEE 802 MAC Address in the following format:
+
+ IPv4 case: 00-00-5E-00-01-{VRID} (in hex, in Internet-standard bit-
+ order)
+
+ The first three octets are derived from the IANA's Organizational
+ Unique Identifier (OUI). The next two octets (00-01) indicate the
+ address block assigned to the VRRP for IPv4 protocol. {VRID} is the
+ VRRP Virtual Router Identifier. This mapping provides for up to 255
+ IPv4 VRRP routers on a network.
+
+ IPv6 case: 00-00-5E-00-02-{VRID} (in hex, in Internet-standard bit-
+ order)
+
+ The first three octets are derived from the IANA's OUI. The next two
+ octets (00-02) indicate the address block assigned to the VRRP for
+ IPv6 protocol. {VRID} is the VRRP Virtual Router Identifier. This
+ mapping provides for up to 255 IPv6 VRRP routers on a network.
+
+7.4. IPv6 Interface Identifiers
+
+ IPv6 routers running VRRP MUST create their Interface Identifiers in
+ the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet
+ Networks" [RFC2464]). They MUST NOT use the virtual router MAC
+ address to create the Modified Extended Unique Identifier (EUI)-64
+ identifiers.
+
+ 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.
+
+
+
+
+
+
+
+
+
+Nadas Standards Track [Page 28]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+8. Operational Issues
+
+8.1. IPv4
+
+8.1.1. ICMP Redirects
+
+ ICMP redirects may be used normally when VRRP is running between a
+ group of routers. This allows VRRP to be used in environments where
+ the topology is not symmetric.
+
+ The IPv4 source address of an ICMP redirect should be the address
+ that the end-host used when making its next-hop routing decision. If
+ a VRRP router is acting as Master for virtual router(s) containing
+ addresses it does not own, then it must determine which virtual
+ router the packet was sent to when selecting the redirect source
+ address. One method to deduce the virtual router used is to examine
+ the destination MAC address in the packet that triggered the
+ redirect.
+
+ It may be useful to disable redirects for specific cases where VRRP
+ is being used to load-share traffic between a number of routers in a
+ symmetric topology.
+
+8.1.2. Host ARP Requests
+
+ When a host sends an ARP request for one of the virtual router IPv4
+ addresses, the Virtual Router Master MUST respond to the ARP request
+ with an ARP response that indicates the virtual 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 Virtual Router Master MUST NOT respond with its physical
+ MAC address in the ARP response. This allows the client to always
+ use the same MAC address regardless of the current Master router.
+
+ When a VRRP router restarts or boots, it SHOULD NOT send any ARP
+ messages using its physical MAC address for the IPv4 address it owns;
+ it should only send ARP messages that include virtual MAC addresses.
+
+ This may entail the following:
+
+ o When configuring an interface, Virtual Router Master routers
+ should broadcast a gratuitous ARP request containing the virtual
+ router MAC address for each IPv4 address on that interface.
+
+ o At system boot, when initializing interfaces for VRRP operation,
+ delay gratuitous ARP requests and ARP responses until both the
+ IPv4 address and the virtual router MAC address are configured.
+
+
+
+
+Nadas Standards Track [Page 29]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ o When, for example, ssh access to a particular VRRP router is
+ required, an IP address known to belong to that router must be
+ used.
+
+8.1.3. Proxy ARP
+
+ If Proxy ARP is to be used on a VRRP router, then the VRRP router
+ must advertise the virtual router MAC address in the Proxy ARP
+ message. Doing otherwise could cause hosts to learn the real MAC
+ address of the VRRP router.
+
+8.2. IPv6
+
+8.2.1. ICMPv6 Redirects
+
+ ICMPv6 redirects may be used normally when VRRP is running between a
+ group of routers [RFC4443]. This allows VRRP to be used in
+ environments where the topology is not symmetric (e.g., the VRRP
+ routers do not connect to the same destinations).
+
+ The IPv6 source address of an ICMPv6 redirect should be the address
+ that the end-host used when making its next-hop routing decision. If
+ a VRRP router is acting as Master for virtual router(s) containing
+ addresses it does not own, then it must determine which virtual
+ router the packet was sent to 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.
+
+8.2.2. ND Neighbor Solicitation
+
+ When a host sends an ND Neighbor Solicitation message for the virtual
+ router IPv6 address, the Virtual Router Master MUST respond to the ND
+ Neighbor Solicitation message with the virtual MAC address for the
+ virtual router. The Virtual Router Master MUST NOT respond with its
+ physical MAC address. This allows the client to always use the same
+ MAC address regardless of the current Master router.
+
+ When a Virtual Router Master sends an ND Neighbor Solicitation
+ message for a host's IPv6 address, the Virtual Router Master MUST
+ include the virtual MAC address for the virtual router if it sends a
+ source link-layer address option in the neighbor solicitation
+ message. It MUST NOT use its physical MAC address in the source
+ link-layer address option.
+
+ When a VRRP router restarts or boots, it SHOULD NOT send any ND
+ messages with its physical MAC address for the IPv6 address it owns;
+ it should only send ND messages that include virtual MAC addresses.
+
+
+
+Nadas Standards Track [Page 30]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ This may entail the following:
+
+ o When configuring an interface, Virtual Router Master routers
+ should send an unsolicited ND Neighbor Advertisement message
+ containing the virtual router MAC address for the IPv6 address on
+ that interface.
+
+ o At system boot, when initializing interfaces for VRRP operation,
+ all ND Router and Neighbor Advertisements and Solicitation
+ messages must be delayed until both the IPv6 address and the
+ virtual router MAC address are configured.
+
+ Note that on a restarting Master router where the VRRP protected
+ address is the interface address, (that is, priority 255) duplicate
+ address detection (DAD) may fail, as the Backup router may answer
+ that it owns the address. One solution is to not run DAD in this
+ case.
+
+8.2.3. Router Advertisements
+
+ When a Backup VRRP router has become Master for a virtual router, it
+ is responsible for sending Router Advertisements for the virtual
+ router as specified in Section 6.4.3. The Backup routers must be
+ configured to send the same Router Advertisement options as the
+ address owner.
+
+ Router Advertisement options that advertise special services (e.g.,
+ Home Agent Information Option) that are present in the address owner
+ should not be sent by the address owner unless the Backup routers are
+ prepared to assume these services in full and have a complete and
+ synchronized database for this service.
+
+8.3. IPvX
+
+8.3.1. Potential Forwarding Loop
+
+ If it is not the address owner, a VRRP router SHOULD NOT forward
+ packets addressed to the IPvX address for which it becomes Master.
+ Forwarding these packets would result in unnecessary traffic. Also,
+ in the case of LANs that receive packets they transmit (e.g., Token
+ Ring), this can result in a forwarding loop that is only terminated
+ when the IPvX TTL expires.
+
+ One such mechanism for VRRP routers is to add/delete a reject host
+ route for each adopted IPvX address when transitioning to/from MASTER
+ state.
+
+
+
+
+
+Nadas Standards Track [Page 31]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+8.3.2. Recommendations Regarding Setting Priority Values
+
+ A priority value of 255 designates a particular router as the "IPvX
+ address owner". Care must be taken not to configure more than one
+ router on the link in this way for a single VRID.
+
+ Routers with priority 255 will, as soon as they start up, preempt all
+ lower-priority routers. No more than one router on the link is to be
+ configured with priority 255, especially if preemption is set. If no
+ router has this priority, and preemption is disabled, then no
+ preemption will occur.
+
+ When there are multiple Backup routers, their priority values should
+ be uniformly distributed. For example, if one Backup router has the
+ default priority of 100 and another Backup Router is added, a
+ priority of 50 would be a better choice for it than 99 or 100, in
+ order to facilitate faster convergence.
+
+8.4. VRRPv3 and VRRPv2 Interoperation
+
+8.4.1. Assumptions
+
+ 1. VRRPv2 and VRRPv3 interoperation is optional.
+
+ 2. 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.
+
+8.4.2. VRRPv3 Support of VRRPv2
+
+ As mentioned above, this support is intended for upgrade scenarios
+ and is NOT recommended for permanent deployments.
+
+ An implementation MAY implement a configuration flag that tells it to
+ listen for and send both VRRPv2 and VRRPv3 advertisements.
+
+ When a virtual router is configured this way and is the Master, it
+ MUST send both types at the configured rate, even if sub-second.
+
+ When a virtual router is configured this way and is the Backup, it
+ should time out based on the rate advertised by the Master; in the
+ case of a VRRPv2 Master, this means it must translate the timeout
+ value it receives (in seconds) into centiseconds. Also, a Backup
+ should ignore VRRPv2 advertisements from the current Master if it is
+ also receiving VRRPv3 packets from it. It MAY report when a VRRPv3
+ Master is *not* sending VRRPv2 packets: that suggests they don't
+ agree on whether they're supporting VRRPv2 routers.
+
+
+
+
+Nadas Standards Track [Page 32]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+8.4.3. VRRPv3 Support of VRRPv2 Considerations
+
+8.4.3.1. Slow, High-Priority Masters
+
+ See also Section 5.2.7, "Maximum Advertisement Interval
+ (Max Adver Int)".
+
+ The VRRPv2 Master router interacting with a sub-second VRRPv3 Backup
+ router is the most important example of this.
+
+ A VRRPv2 implementation should not be given a higher priority than a
+ VRRPv2/VRRPv3 implementation it is interacting with if the VRRPv2/
+ VRRPv3 rate is sub-second.
+
+8.4.3.2. Overwhelming VRRPv2 Backups
+
+ It seems possible that a VRRPv3 Master router sending at centisecond
+ rates could potentially overwhelm a VRRPv2 Backup router with
+ potentially unclear results.
+
+ In this upgrade case, a deployment should initially run the VRRPv3
+ Master routers with lower frequencies (e.g., 100 centiseconds) until
+ the VRRPv2 routers are upgraded. Then, once the deployment has
+ convinced itself that VRRPv3 is working properly, the VRRPv2 support
+ may be unconfigured and then the desired sub-second rates configured.
+
+9. Security Considerations
+
+ VRRP for IPvX does not currently include any type of authentication.
+ Earlier versions of the VRRP (for IPv4) specification included
+ several types of authentication ranging from none to strong.
+ Operational experience and further analysis determined that these did
+ not provide sufficient security to overcome the vulnerability of
+ misconfigured secrets, causing multiple Masters 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 a VRRP Master, creating multiple Masters.
+ Authentication of VRRP messages could have prevented a hostile node
+ from causing all properly functioning routers from going into Backup
+ state. However, having multiple Masters 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 and create
+ the same effect as having all routers go into Backup.
+
+
+
+
+
+
+
+
+Nadas Standards Track [Page 33]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ Some L2 switches provide the capability to filter out, for example,
+ ARP and/or ND messages from end-hosts on a switch-port basis. This
+ mechanism could also filter VRRP messages from switch ports
+ associated with end-hosts and can be considered for deployments with
+ untrusted hosts.
+
+ It should be noted that these attacks are not worse and are a subset
+ of the attacks that any node attached to a LAN can do independently
+ of VRRP. The kind of attacks a malicious node on a LAN can do
+ include promiscuously receiving packets for any router's MAC address;
+ sending packets with the router's MAC address as the source MAC
+ address in the L2 header to tell the L2 switches to send packets
+ addressed to the router to the malicious node instead of the router;
+ send redirects to tell the hosts to send their traffic somewhere
+ else; send unsolicited ND replies; answer ND requests; etc. All of
+ this can be done independently of implementing VRRP. VRRP does not
+ add to these vulnerabilities.
+
+ Independent of any authentication type, VRRP includes a mechanism
+ (setting TTL = 255, checking on receipt) that protects against VRRP
+ packets being injected from another remote network. This limits most
+ vulnerabilities to local attacks.
+
+ VRRP does not provide any confidentiality. Confidentiality is not
+ necessary for the correct operation of VRRP, and there is no
+ information in the VRRP messages that must be kept secret from other
+ nodes on the LAN.
+
+ In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND)
+ is deployed, VRRP is compatible with the "trust anchor" and "trust
+ anchor or cga" modes of SEND [RFC3971]. The SEND configuration needs
+ to give the Master and Backup routers the same prefix delegation in
+ the certificates so that Master and Backup routers advertise the same
+ set of subnet prefixes. However, the Master and Backup routers
+ should have their own key pairs to avoid private key sharing.
+
+10. Contributors and Acknowledgments
+
+ The editor would like to thank V. Ullanatt for his review of an early
+ version. This document consists of very little new material (there
+ is some new text in Appendix A) and was created by merging and
+ "xml-izing" [VRRP-IPv6] and [RFC3768], and then adding in the changes
+ discussed recently on the Virtual Router Redundancy Protocol working
+ group's mailing list. R. Hinden is the author and J. Cruz the editor
+ of the former. The contributors for the latter appear below.
+
+
+
+
+
+
+Nadas Standards Track [Page 34]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ The IPv6 text in this specification is based on [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.
+
+ The author of [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.
+
+ The IPv4 text in this specification is based on [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.
+
+11. IANA Considerations
+
+ IANA has assigned an IPv6 link-local scope multicast address for VRRP
+ for IPv6. The IPv6 multicast address is as follows:
+
+ FF02:0:0:0:0:0:0:12
+
+ The values assigned address should be entered into Section 5.1.2.2.
+
+ The IANA has reserved a block of IANA Ethernet unicast addresses for
+ VRRP for IPv6 in the range
+
+ 00-00-5E-00-02-00 to 00-00-5E-00-02-FF (in hex)
+
+ Similar assignments are documented at:
+
+ http://www.iana.org
+
+12. References
+
+12.1. Normative References
+
+ [ISO.10038.1993] International Organization for Standardization,
+ "Information technology - Telecommunications and
+ information exchange between systems - Local area
+ networks - Media access control (MAC) bridges", ISO
+ Standard 10038, 1993.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Nadas Standards Track [Page 35]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
+ Version 6 (IPv6) Specification", RFC 2460,
+ December 1998.
+
+ [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol
+ (VRRP)", RFC 3768, April 2004.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed.,
+ "Internet Control Message Protocol (ICMPv6) for the
+ Internet Protocol Version 6 (IPv6) Specification",
+ RFC 4443, March 2006.
+
+ [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
+ Soliman, "Neighbor Discovery for IP version 6
+ (IPv6)", RFC 4861, September 2007.
+
+12.2. Informative References
+
+ [VRRP-IPv6] Hinden, R. and J. Cruz, "Virtual Router Redundancy
+ Protocol for IPv6", Work in Progress, March 2007.
+
+ [IPSTB] Higginson, P. and M. Shand, "Development of Router
+ Clusters to Provide Fast Failover in IP Networks",
+ Digital Technical Journal, Volume 9 Number 3,
+ Winter 1997.
+
+ [IPX] Novell Incorporated, "IPX Router Specification
+ Version 1.10", October 1992.
+
+ [RFC1071] Braden, R., Borman, D., Partridge, C., and W.
+ Plummer, "Computing the Internet checksum", RFC
+ 1071, September 1988.
+
+ [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages",
+ RFC 1256, September 1991.
+
+ [RFC1469] Pusateri, T., "IP Multicast over Token-Ring Local
+ Area Networks", RFC 1469, June 1993.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
+ RFC 2131, March 1997.
+
+ [RFC2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot
+ Standby Router Protocol (HSRP)", RFC 2281, March
+ 1998.
+
+
+
+Nadas Standards Track [Page 36]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+ 1998.
+
+ [RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R.,
+ Mitzel, D., Hunt, P., Higginson, P., Shand, M., and
+ A. Lindem, "Virtual Router Redundancy Protocol",
+ RFC 2338, April 1998.
+
+ [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
+ November 1998.
+
+ [RFC2464] Crawford, M., "Transmission of IPv6 Packets over
+ Ethernet Networks", RFC 2464, December 1998.
+
+ [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P.
+ Nikander, "SEcure Neighbor Discovery (SEND)", RFC
+ 3971, March 2005.
+
+ [TKARCH] IBM Incorporated, "IBM Token-Ring Network,
+ Architecture Specification, Publication
+ SC30-3374-02, Third Edition", September 1989.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadas Standards Track [Page 37]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+Appendix A. Operation over FDDI, Token Ring, and ATM LANE
+
+A.1. Operation over FDDI
+
+ FDDI interfaces remove from the FDDI ring frames that have a source
+ MAC address matching the device's hardware address. Under some
+ conditions, such as router isolations, ring failures, protocol
+ transitions, etc., VRRP may cause there to be more than one Master
+ router. If a Master router installs the virtual router MAC address
+ as the hardware address on a FDDI device, then other Masters'
+ ADVERTISEMENTS will be removed from the ring during the Master
+ convergence, and convergence will fail.
+
+ To avoid this, an implementation SHOULD configure the virtual router
+ MAC address by adding a unicast MAC filter in the FDDI device, rather
+ than changing its hardware MAC address. This will prevent a Master
+ router from removing any ADVERTISEMENTS it did not originate.
+
+A.2. Operation over Token Ring
+
+ Token Ring has several characteristics that make running VRRP
+ difficult. These include the following:
+
+ o In order to switch to a new Master located on a different bridge
+ Token-Ring segment from the previous Master when using source-
+ route bridges, a mechanism is required to update cached source-
+ route information.
+
+ o No general multicast mechanism is supported across old and new
+ Token-Ring adapter implementations. While many newer Token-Ring
+ adapters support group addresses, Token-Ring functional-address
+ support is the only generally available multicast mechanism. Due
+ to the limited number of Token-Ring functional addresses, these
+ may collide with other usage of the same Token-Ring functional
+ addresses.
+
+ Due to these difficulties, the preferred mode of operation over Token
+ Ring will be to use a Token-Ring functional address for the VRID
+ virtual MAC address. Token-Ring functional addresses have the two
+ high-order bits in the first MAC address octet set to B'1'. They
+ range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format).
+ However, unlike multicast addresses, there is only one unique
+ functional address per bit position. The functional addresses
+ 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by the
+ Token-Ring Architecture [TKARCH] for user-defined applications.
+ However, since there are only 12 user-defined Token-Ring functional
+ addresses, there may be other non-IPvX protocols using the same
+ functional address. Since the Novell IPX [IPX] protocol uses the
+
+
+
+Nadas Standards Track [Page 38]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ 03-00-00-10-00-00 functional address, operation of VRRP over Token
+ Ring will avoid use of this functional address. In general, Token-
+ Ring VRRP users will be responsible for resolution of other user-
+ defined Token-Ring functional address conflicts.
+
+ VRIDs are mapped directly to Token-Ring functional addresses. In
+ order to decrease the likelihood of functional-address conflicts,
+ allocation will begin with the largest functional address. Most non-
+ IPvX protocols use the first or first couple user-defined functional
+ addresses, and it is expected that VRRP users will choose VRIDs
+ sequentially, starting with 1.
+
+ VRID Token-Ring Functional Address
+ ---- -----------------------------
+ 1 03-00-02-00-00-00
+ 2 03-00-04-00-00-00
+ 3 03-00-08-00-00-00
+ 4 03-00-10-00-00-00
+ 5 03-00-20-00-00-00
+ 6 03-00-40-00-00-00
+ 7 03-00-80-00-00-00
+ 8 03-00-00-01-00-00
+ 9 03-00-00-02-00-00
+ 10 03-00-00-04-00-00
+ 11 03-00-00-08-00-00
+
+ Or, more succinctly, octets 3 and 4 of the functional address are
+ equal to (0x4000 >> (VRID - 1)) in non-canonical format.
+
+ Since a functional address cannot be used as a MAC-level source
+ address, the real MAC address is used as the MAC source address in
+ VRRP advertisements. This is not a problem for bridges, since
+ packets addressed to functional addresses will be sent on the
+ spanning-tree explorer path [ISO.10038.1993].
+
+ The functional-address mode of operation MUST be implemented by
+ routers supporting VRRP on Token Ring.
+
+ Additionally, routers MAY support the unicast mode of operation to
+ take advantage of newer Token-Ring adapter implementations that
+ support non-promiscuous reception for multiple unicast MAC addresses
+ and to avoid both the multicast traffic and usage conflicts
+ associated with the use of Token-Ring functional addresses. Unicast
+ mode uses the same mapping of VRIDs to virtual MAC addresses as
+ Ethernet. However, one important difference exists. ND
+ request/reply packets contain the virtual MAC address as the source
+ MAC address. The reason for this is that some Token-Ring driver
+
+
+
+
+Nadas Standards Track [Page 39]
+
+RFC 5798 VRRPv3 for IPv4 and IPv6 March 2010
+
+
+ implementations keep a cache of MAC address/source-routing
+ information independent of the ND cache.
+
+ Hence, these implementations have to receive a packet with the
+ virtual MAC address as the source address in order to transmit to
+ that MAC address in a source-route-bridged network.
+
+ Unicast mode on Token Ring has one limitation that should be
+ considered. If there are VRID routers on different source-route-
+ bridge segments, and there are host implementations that keep their
+ source-route information in the ND cache and do not listen to
+ gratuitous NDs, these hosts will not update their ND source-route
+ information correctly when a switchover occurs. The only possible
+ solution is to put all routers with the same VRID on the same source-
+ route-bridge segment and use techniques to prevent that bridge
+ segment from being a single point of failure. These techniques are
+ beyond the scope of this document.
+
+ For both the multicast and unicast mode of operation, VRRP
+ advertisements sent to 224.0.0.18 should be encapsulated as described
+ in [RFC1469].
+
+A.3. Operation over ATM LANE
+
+ Operation of VRRP over ATM LANE on routers with ATM LANE interfaces
+ and/or routers behind proxy LAN Emulation Clients (LECs) are beyond
+ the scope of this document.
+
+Author's Address
+
+ Stephen Nadas (editor)
+ Ericsson
+ 900 Chelmsford St., T3 4th Floor
+ Lowell, MA 01851
+ USA
+
+ Phone: +1 978 275 7448
+ EMail: stephen.nadas@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadas Standards Track [Page 40]
+