draft-ietf-vrrp-spec-03.txt   draft-ietf-vrrp-spec-04.txt 
INTERNET-DRAFT S. Knight INTERNET-DRAFT S. Knight
October 23, 1997 D. Weaver November 21, 1997 D. Weaver
Ascend Communications, Inc. Ascend Communications, Inc.
D. Whipple D. Whipple
Microsoft, Inc. Microsoft, Inc.
R. Hinden R. Hinden
D. Mitzel D. Mitzel
P. Hunt P. Hunt
Ipsilon Networks, Inc. Ipsilon Networks, Inc.
P. Higginson P. Higginson
M. Shand M. Shand
Digital Equipment Corp. Digital Equipment Corp.
Acee Lindem
IBM Corporation
Virtual Router Redundancy Protocol Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-03.txt> <draft-ietf-vrrp-spec-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
This internet draft expires on April 23, 1998. This internet draft expires on May 21, 1998.
Abstract Abstract
This memo defines the Virtual Router Redundancy Protocol (VRRP). This memo defines the Virtual Router Redundancy Protocol (VRRP).
VRRP specifies an election protocol that dynamically allows a set of VRRP specifies an election protocol that dynamically assigns
routers running VRRP to backup each other on a LAN. The VRRP router responsibility for a virtual router to one of the VRRP routers on a
controlling one or more IP addresses is called the Master router, and LAN. The VRRP router controlling the IP address(es) associated with
forwards packets sent to these IP addresses. The election process a virtual router is called the Master, and forwards packets sent to
provides dynamic fail over in the forwarding responsibility should these IP addresses. The election process provides dynamic fail over
the Master become unavailable. This allows any of the VRRP routers in the forwarding responsibility should the Master become
IP addresses on the LAN to be used as the default first hop router by unavailable. This allows any of the virtual router IP addresses on
end-hosts. The advantage gained from using the VRRP is a higher the LAN to be used as the default first hop router by end-hosts. The
availability default path without requiring configuration of dynamic advantage gained from using VRRP is a higher availability default
routing or router discovery protocols on every end-host. path without requiring configuration of dynamic routing or router
discovery protocols on every end-host.
Table of Contents Table of Contents
1. Introduction...............................................3 1. Introduction...............................................3
2. Required Features..........................................5 2. Required Features..........................................5
3. VRRP Overview..............................................6 3. VRRP Overview..............................................6
4. Sample Configurations......................................8 4. Sample Configurations......................................8
5. Protocol..................................................10 5. Protocol..................................................10
5.1 VRRP Packet Format...................................10 5.1 VRRP Packet Format....................................10
5.2 IP Field Descriptions................................10 5.2 IP Field Descriptions.................................10
5.3 VRRP Field Descriptions..............................11 5.3 VRRP Field Descriptions...............................11
6. Protocol State Machine....................................14 6. Protocol State Machine....................................14
6.1 Parameters.............................................14 6.1 Parameters............................................14
6.2 Timers.................................................14 6.2 Timers................................................15
6.3 State Transition Diagram..............................15 6.3 State Transition Diagram..............................15
6.4 State Descriptions....................................15 6.4 State Descriptions....................................15
7. Sending and Receiving VRRP Packets........................18 7. Sending and Receiving VRRP Packets........................19
7.1 Receiving VRRP Packets................................18 7.1 Receiving VRRP Packets................................19
7.2 Transmitting Packets...................................18 7.2 Transmitting Packets..................................19
7.3 Virtual MAC Address....................................19 7.3 Virtual MAC Address...................................20
8. Operational Issues........................................20 8. Operational Issues........................................20
8.1 ICMP Redirects.......................................20 8.1 ICMP Redirects........................................20
8.2 Host ARP Requests.....................................20 8.2 Host ARP Requests.....................................20
8.3 Proxy ARP.............................................21 8.3 Proxy ARP.............................................21
9. Operation over FDDI and Token Ring........................21 9. Operation over FDDI and Token Ring........................21
10. Security Considerations...................................22 9.1 Operation over FDDI...................................21
10.1 No Authentication.....................................22 9.2 Operation over Token Ring.............................21
10.2 Simple Text Password..................................22 10. Security Considerations...................................24
10.3 IP Authentication Header..............................22 10.1 No Authentication....................................24
11. Acknowledgments...........................................23 10.2 Simple Text Password.................................24
12. References................................................24 10.3 IP Authentication Header.............................25
13. Authors' Addresses........................................24 11. Acknowledgments...........................................25
14. Changes from Previous Drafts..............................26 12. References................................................26
13. Authors' Addresses........................................27
14. Changes from Previous Drafts..............................29
1. Introduction 1. Introduction
There are a number of methods that an end-host can use to determine There are a number of methods that an end-host can use to determine
its first hop router towards a particular IP destination. These its first hop router towards a particular IP destination. These
include running (or snooping) a dynamic routing protocol such as include running (or snooping) a dynamic routing protocol such as
Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running
an ICMP router discovery client [DISC] or using a statically an ICMP router discovery client [DISC] or using a statically
configured default route. configured default route.
skipping to change at page 3, line 37 skipping to change at page 3, line 37
operation is likely to persist as dynamic host configuration operation is likely to persist as dynamic host configuration
protocols [DHCP] are deployed, which typically provide configuration protocols [DHCP] are deployed, which typically provide configuration
for an end-host IP address and default gateway. However, this for an end-host IP address and default gateway. However, this
creates a single point of failure. Loss of the default router creates a single point of failure. Loss of the default router
results in a catastrophic event, isolating all end-hosts that are results in a catastrophic event, isolating all end-hosts that are
unable to detect any alternate path that may be available. unable to detect any alternate path that may be available.
The Virtual Router Redundancy Protocol (VRRP) is designed to The Virtual Router Redundancy Protocol (VRRP) is designed to
eliminate the single point of failure inherent in the static default eliminate the single point of failure inherent in the static default
routed environment. VRRP specifies an election protocol that routed environment. VRRP specifies an election protocol that
dynamically allows a set of routers to backup each other. The VRRP dynamically assigns responsibility for a virtual router to one of the
router controlling one or more IP addresses is called the Master VRRP routers on a LAN. The VRRP router controlling the IP
router, and forwards packets sent to these IP addresses. The address(es) associated with a virtual router is called the Master,
election process provides dynamic fail-over in the forwarding and forwards packets sent to these IP addresses. The election
responsibility should the Master become unavailable. Any of the IP process provides dynamic fail-over in the forwarding responsibility
addresses on a virtual router can then be used as the default first should the Master become unavailable. Any of the virtual router's IP
hop router by end-hosts. The advantage gained from using the VRRP is addresses on a LAN can then be used as the default first hop router
a higher availability default path without requiring configuration of by end-hosts. The advantage gained from using VRRP is a higher
dynamic routing or router discovery protocols on every end-host. availability default path without requiring configuration of dynamic
routing or router discovery protocols on every end-host.
VRRP provides a function similar to a Cisco Systems, Inc. proprietary VRRP provides a function similar to a Cisco Systems, Inc. proprietary
protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a
Digital Equipment Corporation, Inc. proprietary protocol named IP Digital Equipment Corporation, Inc. proprietary protocol named IP
Standby Protocol. Standby Protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
1.1 Scope 1.1 Scope
The remainder of this document describes the features, design goals, The remainder of this document describes the features, design goals,
and theory of operation of VRRP. The message formats, protocol and theory of operation of VRRP. The message formats, protocol
processing rules and state machine that guarantee convergence to a processing rules and state machine that guarantee convergence to a
single Master router are presented. Finally, operational issues single Virtual Router Master are presented. Finally, operational
related to MAC address mapping, handling of ARP requests, generation issues related to MAC address mapping, handling of ARP requests,
of ICMP redirect messages, and security issues are addressed. generation of ICMP redirect messages, and security issues are
addressed.
This protocol is intended for use with IPv4 routers only. A separate This protocol is intended for use with IPv4 routers only. A separate
specification will be produced if it is decided that similar specification will be produced if it is decided that similar
functionality is desirable in an IPv6 environment. functionality is desirable in an IPv6 environment.
1.2 Definitions 1.2 Definitions
Virtual Router One of a set of routers running VRRP on a LAN. VRRP Router A router running the Virtual Router Redundancy
Protocol. It may participate in one or more
virtual routers.
IP Address Owner The virtual router than has the IP address(es) Virtual Router A Virtual Router Identifier with a set of
as real interface address(es). This is the associated IP address(es) across a common LAN.
router that, when up, will respond to packets This is the abstract object that is managed by
addressed to one of these IP addresses for ICMP Virtual Router Redundancy Protocol. A VRRP
pings, TCP connections, etc. router may backup one or more virtual routers.
IP Address Owner The router that has the IP address(es) as real
interface address(es). This is the router
that, when up, will respond to packets
addressed to one of these IP addresses for
ICMP pings, TCP connections, etc.
Primary IP Address An IP address selected from the set of real Primary IP Address An IP address selected from the set of real
interface addresses. One possible selection interface addresses. One possible selection
algorithm is to always select the first address. algorithm is to always select the first
VRRP advertisements are always sent using the address. VRRP advertisements are always sent
primary IP address as the source of the IP using the primary IP address as the source of
packet. the IP packet.
Master Router The virtual router that is assuming the Virtual Router Master The VRRP router that is assuming the
responsibility of forwarding packets sent to the responsibility of forwarding packets sent to
IP addresses associated with a virtual router the IP address(es) associated with the virtual
and answering ARP requests for these IP router, and answering ARP requests for these
addresses. The Master Router may or may not be IP addresses. Note that if the IP address
the owner. Note that if the IP address owner is owner is available, then it will always become
available, then it will always be the master the Master.
router.
Backup Router The set of virtual routers available to assume Virtual Router Backup The set of VRRP routers available to assume
forwarding responsibility for a virtual router forwarding responsibility for a virtual router
should the current master router fail. should the current Master fail.
2.0 Required Features 2.0 Required Features
This section outlines the set of features that were considered This section outlines the set of features that were considered
mandatory and that guided the design of VRRP. mandatory and that guided the design of VRRP.
2.1 IP Address Backup 2.1 IP Address Backup
Backup of IP addresses is the primary function of the Virtual Router Backup of IP addresses is the primary function of the Virtual Router
Redundancy Protocol. While providing election of a Master router and Redundancy Protocol. While providing election of a Virtual Router
the additional functionality described below, the protocol should Master and the additional functionality described below, the protocol
strive to: should strive to:
- Minimize the duration of black holes. - Minimize the duration of black holes.
- Minimize the steady state bandwidth overhead and processing - Minimize the steady state bandwidth overhead and processing
complexity. complexity.
- Function over a wide variety of multiaccess LAN technologies - Function over a wide variety of multiaccess LAN technologies
capable of supporting IP traffic. capable of supporting IP traffic.
- Provide for election of multiple virtual routers on a network for - Provide for election of multiple virtual routers on a network for
load balancing or in support of multiple logical IP subnets on a load balancing
single LAN segment. - Support of multiple logical IP subnets on a single LAN segment.
2.2 Preferred Path Indication 2.2 Preferred Path Indication
A simple model of Master election among a set of redundant routers is A simple model of Master election among a set of redundant routers is
to treat each router with equal preference and claim victory after to treat each router with equal preference and claim victory after
converging to any router as Master. However, there are likely to be converging to any router as Master. However, there are likely to be
many environments where there is a distinct preference (or range of many environments where there is a distinct preference (or range of
preferences) among the set of redundant routers. For example, this preferences) among the set of redundant routers. For example, this
preference may be based upon access link cost or speed, router preference may be based upon access link cost or speed, router
performance or reliability, or other policy considerations. The performance or reliability, or other policy considerations. The
skipping to change at page 6, line 38 skipping to change at page 7, line 4
message immediately after transitioning to Master to update the message immediately after transitioning to Master to update the
station learning; and 3) trigger periodic messages from the Master to station learning; and 3) trigger periodic messages from the Master to
maintain the station learning cache. maintain the station learning cache.
3.0 VRRP Overview 3.0 VRRP Overview
VRRP specifies an election protocol to provide the virtual router VRRP specifies an election protocol to provide the virtual router
function described earlier. All protocol messaging is performed function described earlier. All protocol messaging is performed
using IP multicast datagrams, thus the protocol can operate over a using IP multicast datagrams, thus the protocol can operate over a
variety of multiaccess LAN technologies supporting IP multicast. variety of multiaccess LAN technologies supporting IP multicast.
Each VRRP virtual router has a single well-known MAC address Each VRRP virtual router has a single well-known MAC address
allocated to it. This document currently only details the mapping to allocated to it. This document currently only details the mapping to
networks using the IEEE 802 48-bit MAC address. The virtual router networks using the IEEE 802 48-bit MAC address. The virtual router
MAC address is used as the source in all periodic messages sent by MAC address is used as the source in all periodic VRRP messages sent
the Master router to enable bridge learning in an extended LAN. by the Master router to enable bridge learning in an extended LAN.
A virtual router is identified by its virtual router identifier. A A virtual router is defined by its virtual router identifier (VRID)
VRRP router has a set of addresses that it owns and one or more other and a set of IP addresses. A VRRP router may associate a virtual
virtual routers it is responsible for backing up. On an interface router with its real addresses on an interface, and may also be
running VRRP, each VRRP router must be configured with a virtual configured with additional virtual router mappings and priority for
router identifier for the addresses it owns, and the other virtual virtual routers it is willing to backup. The mapping between VRID
router identifiers and associated IP addresses that it is responsible and addresses must be coordinated among all VRRP routers on a LAN.
for backing up. In addition, each VRRP router is assigned a priority However, there is no restriction against reusing a VRID with a
to indicate it's preference in Master election for each virtual different address mapping on different LANs. The scope of each
router. Multiple virtual routers can be elected on a network and a virtual router is restricted to a single LAN.
single router can backup one or more virtual routers.
To minimize network traffic, only the Master router sends periodic To minimize network traffic, only the Master for each virtual router
Advertisement messages. A Backup router will not attempt to pre-empt sends periodic VRRP Advertisement messages. A Backup router will not
the Master unless it has higher priority. This eliminates service attempt to pre-empt the Master unless it has higher priority. This
disruption unless a more preferred path becomes available. It's also eliminates service disruption unless a more preferred path becomes
possible to administratively prohibit all pre-emption attempts. The available. It's also possible to administratively prohibit all pre-
only exception to this is that the owner will always become master emption attempts. The only exception is a VRRP router will always
when it is up. If the Master becomes unavailable then the highest become Master of any virtual router associated with addresses it
priority Backup will transition to Master after a short delay, owns. If the Master becomes unavailable then the highest priority
providing a controlled transition of the virtual router Backup will transition to Master after a short delay, providing a
responsibility with minimal service interruption. controlled transition of the virtual router responsibility with
minimal service interruption.
VRRP defines three types of authentication providing simple VRRP defines three types of authentication providing simple
deployment in insecure environments, added protection against deployment in insecure environments, added protection against
misconfiguration, and strong sender authentication in security misconfiguration, and strong sender authentication in security
conscious environments. Analysis of the protection provided and conscious environments. Analysis of the protection provided and
vulnerability of each mechanism is deferred to Section 10.0 Security vulnerability of each mechanism is deferred to Section 10.0 Security
Considerations. In addition new authentication types and data can be Considerations. In addition new authentication types and data can be
defined in the future without affecting the format of the fixed defined in the future without affecting the format of the fixed
portion of the protocol packet, thus preserving backward compatible portion of the protocol packet, thus preserving backward compatible
operation. operation.
skipping to change at page 8, line 40 skipping to change at page 8, line 48
Legend: Legend:
---+---+---+-- = 802 network, Ethernet or FDDI ---+---+---+-- = 802 network, Ethernet or FDDI
H = Host computer H = Host computer
MR = Master Router MR = Master Router
BR = Backup Router BR = Backup Router
* = IP Address * = IP Address
(IP) = default router for hosts (IP) = default router for hosts
The above configuration shows a simple VRRP scenario. In this The above configuration shows a simple VRRP scenario. In this
configuration, the end-hosts install a default route to the IP configuration, the end-hosts install a default route to the IP
address of one of the virtual routers (IP A) and the routers run address of virtual router #1 (IP A) and the routers run VRRP. The
VRRP. The router on the left (VRID=1) becomes the Master router for router on the left becomes the Master for virtual router #1 (VRID=1)
the IP addresses it owns (IP A) and the router on the right (VRID=2) and the router on the right becomes the Master for virtual router # 2
becomes the Master router for the IP addresses it owns (IP B). Each (VRID=2). Each router also backs up the other router. If the router
router also backs up the other router. If the router on the left on the left should fail, the other router will take over virtual
(VRID=1) should fail, the other router will take over its IP router #1 and its IP addresses, and provide uninterrupted service for
addresses and provide uninterrupted service for the hosts. the hosts.
4.2 Sample Configuration 2 4.2 Sample Configuration 2
The following figure shows a configuration with two virtual routers The following figure shows a configuration with two virtual routers
with the hosts slitting their traffic between them. with the hosts spitting their traffic between them.
VRID=1 VRID=2 VRID=1 VRID=2
+-----+ +-----+ +-----+ +-----+
| MR1 | | MR2 | | MR1 | | MR2 |
| & | | & | | & | | & |
| BR2 | | BR1 | | BR2 | | BR1 |
+-----+ +-----+ +-----+ +-----+
IP A ---------->* *<---------- IP B IP A ---------->* *<---------- IP B
| | | |
| | | |
skipping to change at page 9, line 38 skipping to change at page 9, line 42
Legend: Legend:
---+---+---+-- = 802 network, Ethernet or FDDI ---+---+---+-- = 802 network, Ethernet or FDDI
H = Host computer H = Host computer
MR = Master Router MR = Master Router
BR = Backup Router BR = Backup Router
* = IP Address * = IP Address
(IP) = default router for hosts (IP) = default router for hosts
In the above configuration, half of the hosts install a default route In the above configuration, half of the hosts install a default route
to virtual router 1's IP address (IP A), and the other half of the to virtual router #1's IP address (IP A), and the other half of the
hosts install a default route to virtual router 2's IP address (IP hosts install a default route to virtual router #2's IP address (IP
B). This has the effect of load balancing the outgoing traffic, B). This has the effect of load balancing the outgoing traffic,
while also providing full redundancy. while also providing full redundancy.
5.0 Protocol 5.0 Protocol
The purpose of the VRRP packet is to communicate to all VRRP routers 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 the priority and the state of the Master router associated with the
Virtual Router ID. Virtual Router ID.
VRRP packets are sent encapsulated in IP packets. They are sent to VRRP packets are sent encapsulated in IP packets. They are sent to
an IPv4 multicast address assigned to VRRP. the IPv4 multicast address assigned to VRRP.
5.1 VRRP Packet Format 5.1 VRRP Packet Format
This section defines the format of the VRRP packet and the relevant This section defines the format of the VRRP packet and the relevant
fields in the IP header. fields in the IP header.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs|
skipping to change at page 10, line 48 skipping to change at page 10, line 48
5.2 IP Field Descriptions 5.2 IP Field Descriptions
5.2.1 Source Address 5.2.1 Source Address
The primary IP address of the interface the packet is being sent The primary IP address of the interface the packet is being sent
from. from.
5.2.2 Destination Address 5.2.2 Destination Address
The VRRP IP multicast address assigned by the IANA. It is defined to The IP multicast address as assigned by the IANA for VRRP is:
be:
224.0.0.18
224.0.0.(TBD IANA assignment)
This is a link local scope multicast address. Routers MUST NOT This is a link local scope multicast address. Routers MUST NOT
forward a datagram with this destination address regardless of its forward a datagram with this destination address regardless of its
TTL. TTL.
5.2.3 TTL 5.2.3 TTL
The TTL MUST be set to 255. A VRRP router receiving a packet with The TTL MUST be set to 255. A VRRP router receiving a packet with
the TTL not equal to 255 MUST discard the packet. the TTL not equal to 255 MUST discard the packet.
5.2.4 Protocol 5.2.4 Protocol
The VRRP IP protocol number assigned by the IANA. It is defined to The IP protocol number assigned by the IANA for VRRP is 112
be (TBD). (decimal).
5.3 VRRP Field Descriptions 5.3 VRRP Field Descriptions
5.3.1 Version 5.3.1 Version
The version field specifies the VRRP protocol version of this packet. The version field specifies the VRRP protocol version of this packet.
This document defines version 2. This document defines version 2.
5.3.2 Type 5.3.2 Type
skipping to change at page 11, line 41 skipping to change at page 11, line 40
A packet with unknown type MUST be discarded. A packet with unknown type MUST be discarded.
5.3.3 Virtual Rtr ID (VRID) 5.3.3 Virtual Rtr ID (VRID)
The Virtual Router Identifier (VRID) field identifies the virtual The Virtual Router Identifier (VRID) field identifies the virtual
router this packet is reporting status for. router this packet is reporting status for.
5.3.4 Priority 5.3.4 Priority
The priority field specifies the router's priority for the virtual The priority field specifies the sending VRRP router's priority for
router. Higher values equal higher priority. This field is an 8 bit the virtual router. Higher values equal higher priority. This field
unsigned field. is an 8 bit unsigned integer field.
The priority value for the router that owns the IP address(es) The priority value for the VRRP router that owns the IP address(es)
associated with the virtual router MUST be 255 (decimal). associated with the virtual router MUST be 255 (decimal).
VRRP routers backing up another virtual router MAY use priority VRRP routers backing up a virtual router MUST use priority values
values between 1-254 (decimal). The default priority value for between 1-254 (decimal). The default priority value for VRRP routers
routers backing up another virtual router is 100 (decimal). backing up a virtual router is 100 (decimal).
The priority value zero (0) has special meaning indicating that the The priority value zero (0) has special meaning indicating that the
current Master has stopped participating in VRRP. This is used to current Master has stopped participating in VRRP. This is used to
trigger Backup routers to quickly transition to Master without having trigger Backup routers to quickly transition to Master without having
to wait for the current Master to timeout. to wait for the current Master to timeout.
5.3.5 Count IP Addrs 5.3.5 Count IP Addrs
The number of IP addresses contained in this VRRP advertisement. The number of IP addresses contained in this VRRP advertisement.
5.3.6 Authentication Type 5.3.6 Authentication Type
The authentication type field identifies the authentication method The authentication type field identifies the authentication method
being utilized. Authentication type is unique on a per interface being utilized. Authentication type is unique on a per interface
basis. The authentication type field is an 8 bit number. A packet basis. The authentication type field is an 8 bit unsigned integer.
with unknown authentication type or that does not match the locally A packet with unknown authentication type or that does not match the
configured authentication method MUST be discarded. locally configured authentication method MUST be discarded.
The authentication methods currently defined are: The authentication methods currently defined are:
0 - No Authentication 0 - No Authentication
1 - Simple Text Password 1 - Simple Text Password
2 - IP Authentication Header 2 - IP Authentication Header
5.3.6.1 No Authentication 5.3.6.1 No Authentication
The use of this authentication type means that VRRP protocol The use of this authentication type means that VRRP protocol
skipping to change at page 13, line 48 skipping to change at page 13, line 43
field. These fields are used for troubleshooting misconfigured field. These fields are used for troubleshooting misconfigured
routers. routers.
5.3.10 Authentication Data 5.3.10 Authentication Data
The authentication string is currently only utilized for simple text The authentication string is currently only utilized for simple text
authentication, similar to the simple text authentication found in authentication, similar to the simple text authentication found in
the Open Shortest Path First routing protocol [OSPF]. It is up to 8 the Open Shortest Path First routing protocol [OSPF]. It is up to 8
characters of plain text. If the configured authentication string is characters of plain text. If the configured authentication string is
shorter than 8 bytes, the remaining space MUST be zero-filled. Any shorter than 8 bytes, the remaining space MUST be zero-filled. Any
VRRP packet with an authentication string that does not match its VRRP packet received with an authentication string that does not
configured authentication string SHOULD be discarded. The match the locally configured authentication string MUST be discarded.
authentication string is unique on a per interface basis. The authentication string is unique on a per interface basis.
There is no default value for this field. There is no default value for this field.
6. Protocol State Machine 6. Protocol State Machine
6.1 Parameters 6.1 Parameters
6.1.1 Parameters per Interface 6.1.1 Parameters per Interface
Authentication_Type Type of authentication being used. Values Authentication_Type Type of authentication being used. Values
are defined in section 5.3.6. are defined in section 5.3.6.
Authentication_Data Authentication data specific to the Authentication_Data Authentication data specific to the
Authentication_Type being used. Authentication_Type being used.
6.1.2 Parameters per Virtual Router 6.1.2 Parameters per Virtual Router
Virtual Router Identifier. Configured item in the range 1-255 VRID Virtual Router Identifier. Configured item
(decimal). There is no default. in the range 1-255 (decimal). There is no
default.
Priority Priority value to be used in Master election Priority Priority value to be used by this VRRP
for this virtual router. The value of 255 router in Master election for this virtual
(decimal) is reserved for the router that router. The value of 255 (decimal) is
owns the IP addresses associated with the reserved for the router that owns the IP
virtual router. The value of 0 (zero) is addresses associated with the virtual
reserved for Master router to indicate it router. The value of 0 (zero) is reserved
has stopped running VRRP. The range 1-254 for Master router to indicate it is
(decimal) is available for VRRP routers releasing responsibility for the virtual
backing up the virtual router. The default router. The range 1-254 (decimal) is
value is 100 (decimal). available for VRRP routers backing up the
virtual router. The default value is 100
(decimal).
IP_Addresses One or more IP addresses associated with IP_Addresses One or more IP addresses associated with
this virtual router. Configured item. No this virtual router. Configured item. No
default. default.
Advertisement_Interval Time interval between ADVERTISEMENTS Advertisement_Interval Time interval between ADVERTISEMENTS
(seconds). Default is 1 second. (seconds). Default is 1 second.
Skew_Time Time to skew Master_Down_Interval in Skew_Time Time to skew Master_Down_Interval in
seconds. Calculated as: seconds. Calculated as:
( (256 - Priority) / 256 ) ( (256 - Priority) / 256 )
Master_Down_Interval Time interval for Backup to declare Master Master_Down_Interval Time interval for Backup to declare Master
down (seconds). Calculated as: down (seconds). Calculated as:
(3 * Advertisement_Interval) + Skew_time (3 * Advertisement_Interval) + Skew_time
Preempt_Mode Controls whether a higher priority Backup Preempt_Mode Controls whether a higher priority Backup
router preempts a lower priority Master. router preempts a lower priority Master.
Values are True to preempt and False to not Values are True to allow preemption and
preempt. Default is True. False to not prohibit preemption. Default
is True.
Note: Exception is that the router that owns Note: Exception is that the router that owns
the IP address(es) associated with the the IP address(es) associated with the
virtual router always pre-empts independent virtual router always pre-empts independent
of the setting of this flag. of the setting of this flag.
6.2 Timers 6.2 Timers
Master_Down_Timer Timer that fires when ADVERTISEMENT has not Master_Down_Timer Timer that fires when ADVERTISEMENT has not
been heard for Master_Down_Interval. been heard for Master_Down_Interval.
skipping to change at page 16, line 5 skipping to change at page 16, line 6
| Master | | Backup | | Master | | Backup |
| |<----------------------| | | |<----------------------| |
+---------------+ +---------------+ +---------------+ +---------------+
6.4 State Descriptions 6.4 State Descriptions
In the state descriptions below, the state names are identified by In the state descriptions below, the state names are identified by
{state-name}, and the packets are identified by all upper case {state-name}, and the packets are identified by all upper case
characters. characters.
A VRRP router implements an instance of the state machine for each
virtual router election it is participating in.
6.4.1 Initialize 6.4.1 Initialize
{Initialize} is the state a virtual router takes when it is inactive The purpose of this state is to wait for a Startup event. If a
with respect to the virtual router. The purpose of this state is to Startup event is received, then:
wait for a Startup event. If a Startup event is received, then:
- If the Priority = 255 (i.e., the router owns the IP address(es) - If the Priority = 255 (i.e., the router owns the IP address(es)
associated with the virtual router) associated with the virtual router)
o Send an ADVERTISEMENT o Send an ADVERTISEMENT
o Send a gratuitous ARP request containing the virtual router MAC o Broadcast a gratuitous ARP request containing the virtual
address for each IP address associated with the virtual router. router MAC address for each IP address associated with the
virtual router.
o Set the Adver_Timer to Advertisement_Interval o Set the Adver_Timer to Advertisement_Interval
o Transition to the {Master} state o Transition to the {Master} state
else else
o Set the Master_Down_Timer to Master_Down_Interval o Set the Master_Down_Timer to Master_Down_Interval
o Transition to the {Backup} state o Transition to the {Backup} state
endif endif
6.4.2 Backup 6.4.2 Backup
The purpose of the {Backup} state is to monitor the availability and The purpose of the {Backup} state is to monitor the availability and
state of the Master Router. state of the Master Router.
While in this state, an virtual router MUST do the following: While in this state, a VRRP router MUST do the following:
- MUST NOT respond to ARP requests for the IP address(s) associated - MUST NOT respond to ARP requests for the IP address(s) associated
with this VRID. with the virtual router.
- MUST discard packets with a destination link layer MAC address - MUST discard packets with a destination link layer MAC address
equal to the virtual router MAC address for this VRID. equal to the virtual router MAC address.
- MUST NOT accept packets addressed to the IP address(es) associated - MUST NOT accept packets addressed to the IP address(es) associated
with this VRID. with the virtual router.
- If a Shutdown event is received, then: - If a Shutdown event is received, then:
o Cancel the Master_Down_Timer o Cancel the Master_Down_Timer
o Transition to the {Initialize} state o Transition to the {Initialize} state
endif endif
- If the Master_Down_Timer fires, then: - If the Master_Down_Timer fires, then:
o Send an ADVERTISEMENT o Send an ADVERTISEMENT
o Send a gratuitous ARP request containing their virtual router o Broadcast a gratuitous ARP request containing the virtual
MAC address for each IP address associated with the virtual router MAC address for each IP address associated with the
router virtual router
o Set the Adver_Timer to Advertisement_Interval o Set the Adver_Timer to Advertisement_Interval
o Transition to the {Master} state o Transition to the {Master} state
endif endif
- If an ADVERTISEMENT is received, then: - If an ADVERTISEMENT is received, then:
If the Priority in the ADVERTISEMENT is Zero, then: If the Priority in the ADVERTISEMENT is Zero, then:
o Set the Master_Down_Timer to Skew_Time o Set the Master_Down_Timer to Skew_Time
skipping to change at page 17, line 42 skipping to change at page 17, line 44
endif endif
endif endif
endif endif
6.4.3 Master 6.4.3 Master
While in the {Master} state the router functions as the forwarding While in the {Master} state the router functions as the forwarding
router for the IP address(es) associated with the virtual router. router for the IP address(es) associated with the virtual router.
While in this state, a virtual router MUST do the following: While in this state, a VRRP router MUST do the following:
- MUST respond to ARP requests for the IP address(es) associated - MUST respond to ARP requests for the IP address(es) associated
with the VRID with the virtual router MAC address. with the virtual router.
- MUST forward packets with a destination link layer MAC address - MUST forward packets with a destination link layer MAC address
equal to the virtual router MAC address. equal to the virtual router MAC address.
- MUST NOT accept packets addressed to the IP address(es) associated - MUST NOT accept packets addressed to the IP address(es) associated
for the virtual router if it is not the IP address owner. with the virtual router if it is not the IP address owner.
- MUST accept packets addressed to the IP address(es) if it is the - MUST accept packets addressed to the IP address(es) associated
IP address owner. with the virtual router if it is the IP address owner.
- If a Shutdown event is received, then: - If a Shutdown event is received, then:
o Cancel the Adver_Timer o Cancel the Adver_Timer
o Send an ADVERTISEMENT with Priority = 0 o Send an ADVERTISEMENT with Priority = 0
o Transition to the {Initialize} state o Transition to the {Initialize} state
endif endif
- If the Adver_Timer fires, then: - If the Adver_Timer fires, then:
skipping to change at page 19, line 12 skipping to change at page 19, line 12
endif endif
endif endif
7. Sending and Receiving VRRP Packets 7. Sending and Receiving VRRP Packets
7.1 Receiving VRRP Packets 7.1 Receiving VRRP Packets
Performed the following functions when a VRRP packet is received: Performed the following functions when a VRRP packet is received:
- MUST verify that the IP TTL is 255. - MUST verify that the IP TTL is 255.
- MUST verify the VRRP version
- MUST verify that the received packet length is greater than or - MUST verify that the received packet length is greater than or
equal to the VRRP header equal to the VRRP header
- MUST verify the VRRP checksum - MUST verify the VRRP checksum
- MUST verify the VRRP version
- MUST perform authentication specified by Auth Type - MUST perform authentication specified by Auth Type
If any one of the above checks fails, the receiver MUST discard the If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event and MAY indicate via network management packet, SHOULD log the event and MAY indicate via network management
that an error occurred. that an error occurred.
- MUST verify that the VRID is valid on the receiving interface - MUST verify that the VRID is valid on the receiving interface
If the above checks fails, the receiver MUST discard the packet. If the above check fails, the receiver MUST discard the packet.
- MAY verify that the IP address(es) associated with the VRID are - MAY verify that the IP address(es) associated with the VRID are
valid valid
If the above check fails, the receiver SHOULD log the event and MAY If the above check fails, the receiver SHOULD log the event and MAY
indicate via network management that an error occurred. If the indicate via network management that a misconfiguration was detected.
Priority does not equal 255 (decimal), the receiver MUST drop the If the packet was not generated by the address owner (Priority does
packet. If the Priority equals 255 (decimal) continue processing. not equal 255 (decimal)), the receiver MUST drop the packet,
otherwise continue processing.
- MUST verify that the Adver Interval in the packet is the same as - MUST verify that the Adver Interval in the packet is the same as
the locally configured for this virtual router the locally configured for this virtual router
If the above check fails, the receiver MUST discard the packet, If the above check fails, the receiver MUST discard the packet,
SHOULD log the event and MAY indicate via network management that an SHOULD log the event and MAY indicate via network management that a
error occurred. misconfiguration was detected.
7.2 Transmitting Packets 7.2 Transmitting VRRP Packets
The following operations MUST be performed prior to transmitting a The following operations MUST be performed when transmitting a VRRP
VRRP packet. packet.
- Fill in the VRRP packet fields with the appropriate virtual - Fill in the VRRP packet fields with the appropriate virtual
router configuration state router configuration state
- Compute the VRRP checksum - Compute the VRRP checksum
- Set the source MAC address to Virtual Router MAC Address - Set the source MAC address to Virtual Router MAC Address
- Set the source IP address to interface primary IP address - Set the source IP address to interface primary IP address
- Set the IP protocol to VRRP
- Send the VRRP packet to the VRRP IP multicast group - Send the VRRP packet to the VRRP IP multicast group
Note: VRRP packets are transmitted with the virtual router MAC Note: VRRP packets are transmitted with the virtual router MAC
address as the source MAC address to ensure that learning bridges address as the source MAC address to ensure that learning bridges
correctly determine the LAN segment the virtual router is attached correctly determine the LAN segment the virtual router is attached
to. to.
7.3 Virtual Router MAC Address 7.3 Virtual Router MAC Address
The virtual router MAC address associated with a virtual router is an The virtual router MAC address associated with a virtual router is an
IEEE 802 MAC Address in the following format: IEEE 802 MAC Address in the following format:
skipping to change at page 20, line 18 skipping to change at page 20, line 21
7.3 Virtual Router MAC Address 7.3 Virtual Router MAC Address
The virtual router MAC address associated with a virtual router is an The virtual router MAC address associated with a virtual router is an
IEEE 802 MAC Address in the following format: IEEE 802 MAC Address in the following format:
00-00-5E-XX-XX-{VRID} (in hex in internet standard bit-order) 00-00-5E-XX-XX-{VRID} (in hex in internet standard bit-order)
The first three octets are derived from the IANA's OUI. The next two The first three octets are derived from the IANA's OUI. The next two
octets (to be assigned by the IANA) indicate the address block octets (to be assigned by the IANA) indicate the address block
assigned to the VRRP protocol. {VRID} is the VRRP Router Identifier. assigned to the VRRP protocol. {VRID} is the VRRP Virtual Router
This mapping provides for up to 255 VRRP routers on a network. Identifier. This mapping provides for up to 255 VRRP routers on a
network.
8. Operational Issues 8. Operational Issues
8.1 ICMP Redirects 8.1 ICMP Redirects
ICMP Redirects may be used normally when VRRP is running between a ICMP Redirects may be used normally when VRRP is running between a
group of routers. This allows VRRP to be used in environments where group of routers. This allows VRRP to be used in environments where
the topology is not symmetric. the topology is not symmetric.
When acting as a Master for a VRID it is not the owner, the virtual The IP source address of an ICMP redirect should be the address the
router MUST send ICMP Redirects using the IP address associated with end host used when making its next hop routing decision. If a VRRP
the VRID as the source of the ICMP Redirect. This entails looking at router is acting as Master for virtual router(s) containing addresses
the destination MAC address in the packet that is being redirected it does not own, then it must determine which virtual router the
and selecting the appropriate IP address. 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 is It may be useful to disable Redirects for specific cases where VRRP
VRRP is being used to load share traffic between a number of routers is being used to load share traffic between a number of routers in a
in a symmetric topology. symmetric topology.
8.2 Host ARP Requests 8.2 Host ARP Requests
When a host sends an ARP request for one of the virtual routers IP When a host sends an ARP request for one of the virtual router IP
addresses, the Master router MUST respond to the ARP request with the addresses, the Master virtual router MUST respond to the ARP request
virtual MAC address for the virtual router. The virtual router MUST with the virtual MAC address for the virtual router. The Master
NOT respond with it's physical MAC address. This allows the client virtual router MUST NOT respond with its physical MAC address. This
to always use the same MAC address regardless of the current Master allows the client to always use the same MAC address regardless of
router. The request MUST be handled as a standard ARP reply. the current Master router.
When a virtual router restarts or boots, it SHOULD not send any ARP When a VRRP router restarts or boots, it SHOULD not send any ARP
messages with it's physical MAC addresses for the IP addresses it messages with its physical MAC address for the IP address it owns, it
owns. They should only send ARP messages that include Virtual MAC should only send ARP messages that include Virtual MAC addresses.
addresses. This may entail: This may entail:
- When configuring their interfaces, virtual routers should send a - When configuring an interface, VRRP routers should broadcast a
gratuitous ARP request containing their virtual MAC address for gratuitous ARP request containing the virtual router MAC address
each IP address they own on that interface. for each IP address on that interface.
- At system boot, when initializing any of its IP addresses for - At system boot, when initializing interfaces for VRRP operation;
which VRRP is configured, delay gratuitous ARP requests and ARP delay gratuitous ARP requests and ARP responses until both the IP
responses for that interface until both the IP address and the address and the virtual router MAC address are configured.
virtual MAC address are configured.
8.3 Proxy ARP 8.3 Proxy ARP
If Proxy ARP is to be used on a router running VRRP, then the VRRP If Proxy ARP is to be used on a VRRP router, then the VRRP router
router must advertise the Virtual Router MAC address in the Proxy ARP must advertise the Virtual Router MAC address in the Proxy ARP
message. Doing otherwise could cause hosts to learn the real MAC message. Doing otherwise could cause hosts to learn the real MAC
address of the VRRP routers. address of the VRRP router.
9. Operation over FDDI and Token Ring 9. Operation over FDDI and Token Ring
9.1 Operation over FDDI 9.1 Operation over FDDI
FDDI interfaces strip from the FDDI ring frames that have a source FDDI interfaces remove from the FDDI ring frames that have a source
MAC address matching the device's hardware address. Under some MAC address matching the device's hardware address. Under some
conditions, such as router isolations, ring failures, protocol conditions, such as router isolations, ring failures, protocol
transitions, etc., VRRP may cause there to be more than one Master transitions, etc., VRRP may cause there to be more than one Master
router. If a Master router installs the virtual router MAC address router. If a Master router installs the virtual router MAC address
as the hardware address on a FDDI device, then other Masters' as the hardware address on a FDDI device, then other Masters'
ADVERTISEMENTS will be stripped off the ring during the Master ADVERTISEMENTS will be removed from the ring during the Master
convergence, and convergence will fail. convergence, and convergence will fail.
To avoid this an implementation SHOULD configure the virtual router To avoid this an implementation SHOULD configure the virtual router
MAC address by adding a unicast MAC filter in the FDDI device, rather MAC address by adding a unicast MAC filter in the FDDI device, rather
than changing its hardware MAC address. This will prevent a Master than changing its hardware MAC address. This will prevent a Master
router from stripping any ADVERTISEMENTS it did not originate. router from removing any ADVERTISEMENTS it did not originate.
9.2 Operation over Token Ring 9.2 Operation over Token Ring
Token Ring has several characteristics which make running VRRP Token ring has several characteristics which make running VRRP
problematic. This includes: difficult. These include:
- No general multicast mechanism. Required use of "functional - In order to switch to a new master located on a different bridge
addresses" as a substitute, which may collide with other usage of token ring segment from the previous master when using source
the same "functional addresses". route bridges, a mechanism is required to update cached source
- Token Ring interfaces may have a limited ability to receive on route information.
multiple MAC addresses.
- In order to switch to a new master located on a different physical
ring from the previous master when using source route bridges, a
mechanism is required to update cached source route information.
Due the these issues and the limited knowledge about the detailed - No general multicast mechanism supported across old and new token
operation of Token Ring by the authors, this version of VRRP does not ring adapter implementations. While many newer token ring adapters
work over Token Ring networks. This may be remedied in new version support group addresses, token ring functional address support is
of this document, or in a separate document. 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
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-IP protocols using
the same functional address. Since the Novell IPX [IPX] protocol uses
the 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-
IP 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 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 [802.1D].
The functional address mode of operation MUST be implemented by
routers supporting VRRP on token ring.
Additionally, routers MAY support unicast mode of operation to take
advantage of newer token ring adapter implementations which 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. ARP request/reply packets contain
the virtual MAC address as the source MAC address. The reason for
this is that some token ring driver implementations keep a cache of
MAC address/source routing information independent of the ARP cache.
Hence, these implementations need 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 which should be
considered. If there are VRID routers on different source-route
bridge segments and there are host implementations which keep their
source-route information in the ARP cache and do not listen to
gratuitous ARPs, these hosts will not update their ARP source-route
information correctly when a switch-over occurs. The only possible
solution is to put all routers with the same VRID on the same source-
bridge segment and use techniques to prevent that bridge segment from
being a single point of failure. These techniques are beyond the
scope this document.
For both the multicast and unicast mode of operation, VRRP
advertisements sent to 224.0.0.TBD should be encapsulated as
described in [RFC1469].
10. Security Considerations 10. Security Considerations
VRRP is designed for a range of internetworking environments that may VRRP is designed for a range of internetworking environments that may
employ different security policies. The protocol includes several employ different security policies. The protocol includes several
authentication methods ranging from no authentication, simple clear authentication methods ranging from no authentication, simple clear
text passwords, and strong authentication using IP Authentication text passwords, and strong authentication using IP Authentication
with MD5 HMAC. The details on each approach including possible with MD5 HMAC. The details on each approach including possible
attacks and recommended environments follows. attacks and recommended environments follows.
skipping to change at page 22, line 36 skipping to change at page 24, line 31
(setting TTL=255, checking on receipt) that protects against VRRP (setting TTL=255, checking on receipt) that protects against VRRP
packets being injected from another remote network. This limits most packets being injected from another remote network. This limits most
vulnerabilities to local attacks. vulnerabilities to local attacks.
10.1 No Authentication 10.1 No Authentication
The use of this authentication type means that VRRP protocol The use of this authentication type means that VRRP protocol
exchanges are not authenticated. This type of authentication SHOULD exchanges are not authenticated. This type of authentication SHOULD
only be used in environments were there is minimal security risk and only be used in environments were there is minimal security risk and
little chance for configuration errors (e.g., two VRRP routers on a little chance for configuration errors (e.g., two VRRP routers on a
link). LAN).
10.2 Simple Text Password 10.2 Simple Text Password
The use of this authentication type means that VRRP protocol The use of this authentication type means that VRRP protocol
exchanges are authenticated by a simple clear text password. exchanges are authenticated by a simple clear text password.
This type of authentication is useful to protect against accidental This type of authentication is useful to protect against accidental
misconfiguration of routers on a link. It protects against routers misconfiguration of routers on a LAN. It protects against routers
inadvertently backing up another router. A new router must first be inadvertently backing up another router. A new router must first be
configured with the correct password before it can run VRRP with configured with the correct password before it can run VRRP with
another router. This type of authentication does not protect against another router. This type of authentication does not protect against
hostile attacks where the password can be learned by a node snooping hostile attacks where the password can be learned by a node snooping
VRRP packets on the link. The Simple Text Authentication combined VRRP packets on the LAN. The Simple Text Authentication combined
with the TTL check makes it difficult for a VRRP packet to be sent with the TTL check makes it difficult for a VRRP packet to be sent
from another link to disrupt VRRP operation. from another LAN to disrupt VRRP operation.
This type of authentication is RECOMMENDED when there is minimal risk This type of authentication is RECOMMENDED when there is minimal risk
of nodes on the link actively disrupting VRRP operation. of nodes on a LAN actively disrupting VRRP operation.
10.3 IP Authentication Header 10.3 IP Authentication Header
The use of this authentication type means the VRRP protocol exchanges The use of this authentication type means the VRRP protocol exchanges
are authenticated using the mechanisms defined by the IP are authenticated using the mechanisms defined by the IP
Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP
and AH", [HMAC]. This provides strong protection against and AH", [HMAC]. This provides strong protection against
configuration errors, replay attacks, and packet configuration errors, replay attacks, and packet
corruption/modification. corruption/modification.
This type of authentication is RECOMMENDED when there is limited This type of authentication is RECOMMENDED when there is limited
control over the administration of nodes on the link. While this control over the administration of nodes on a LAN. While this type
type of authentication does protect the operation of VRRP, there are of authentication does protect the operation of VRRP, there are other
other types of attacks that may be employed on shared media links types of attacks that may be employed on shared media links (e.g.,
(e.g., generation of bogus ARP replies) which are independent from generation of bogus ARP replies) which are independent from VRRP and
VRRP and are not protected. are not protected.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Glen Zorn, and Michael Lane, Clark The authors would like to thank Glen Zorn, and Michael Lane, Clark
Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, and Steve
Bellovin, and Acee Lindem for their comments and suggestions. Bellovin for their comments and suggestions.
12. References 12. References
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std
802.1D, 1993 edition.
[AUTH] Atkinson, R., "IP Authentication Header", RFC-1826, August [AUTH] Atkinson, R., "IP Authentication Header", RFC-1826, August
1995. 1995.
[DISC] Deering, S., "ICMP Router Discovery Messages", RFC-1256, [DISC] Deering, S., "ICMP Router Discovery Messages", RFC-1256,
September 1991. September 1991.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC-1541, [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC-1541,
October 1993. October 1993.
[HMAC] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP [HMAC] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP
and AH", Internet Draft, <draft-ietf-ipsec-auth-hmac- and AH", Internet Draft, <draft-ietf-ipsec-auth-hmac-
md5-96-00.txt> , July 1997. md5-96-00.txt> , July 1997.
[HSRP] Li, T., B. Cole, P. Morton, D. Li, "Hot Standby Router [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Hot Standby Router
Protocol (HSRP)", Internet Draft, <draft-li-hsrp-00.txt>, Protocol (HSRP)", Internet Draft, <draft-li-hsrp-00.txt>,
June 1997. June 1997.
[IPX] Novell Incorporated., "IPX Router Specification", Version
1.10, October 1992.
[OSPF] Moy, J., "OSPF version 2", RFC-1583, July 1997. [OSPF] Moy, J., "OSPF version 2", RFC-1583, July 1997.
[RIP] Hedrick, C., "Routing Information Protocol" , RFC-1058, [RIP] Hedrick, C., "Routing Information Protocol" , RFC-1058,
June 1988. June 1988.
[RFC1469] Pusateri, T., "IP over Token Ring LANs", RFC 1469, June
1993.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC-2119, BCP14, March 1997. Requirement Levels", RFC-2119, BCP14, March 1997.
[TKARCH] IBM Token-Ring Network, Architecture Reference, Publication
SC30-3374-02, Third Edition, (September, 1989).
13. Author's Addresses 13. Author's Addresses
Steven Knight Phone: +1 612 943-8990 Steven Knight Phone: +1 612 943-8990
Ascend Communications EMail: Steven.Knight@ascend.com Ascend Communications EMail: Steven.Knight@ascend.com
High Performance Network Division High Performance Network Division
10250 Valley View Road, Suite 113 10250 Valley View Road, Suite 113
Eden Prairie, MN USA 55344 Eden Prairie, MN USA 55344
USA USA
Douglas Weaver Phone: +1 612 943-8990 Douglas Weaver Phone: +1 612 943-8990
skipping to change at page 25, line 29 skipping to change at page 27, line 46
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Peter Hunt Phone: +1 408 990-2093 Peter Hunt Phone: +1 408 990-2093
Ipsilon Networks, Inc. EMail: hunt@ipsilon.com Ipsilon Networks, Inc. EMail: hunt@ipsilon.com
232 Java Drive 232 Java Drive
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
P. Higginson Phone: +44 118 920 6293 P. Higginson Phone: +44 118 920 6293
REO2-F/E9 EMail: higginson@mail.dec.com Digital Equipment Corp. EMail: higginson@mail.dec.com
Digital Equipment Corp.
Digital Park Digital Park
Imperial Way Imperial Way
Reading Reading
Berkshire Berkshire
RG2 0TE RG2 0TE
UK UK
M. Shand Phone: +44 118 920 4424 M. Shand Phone: +44 118 920 4424
REO2-F/D9 EMail: shand@mail.dec.com Digital Equipment Corp. EMail: shand@mail.dec.com
Digital Equipment Corp.
Digital Park Digital Park
Imperial Way Imperial Way
Reading Reading
Berkshire Berkshire
RG2 0TE RG2 0TE
UK UK
Acee Lindem Phone: 1-919-254-1805
IBM Corporation E-Mail: acee@raleigh.ibm.com
P.O. Box 12195
Research Triangle Park, NC 27709
USA
14. Changes from Previous Drafts 14. Changes from Previous Drafts
Changes from <draft-ietf-vrrp-spec-03.txt>
- Added IANA assignments for protocol and multicast address. MAC
prefix still needed.
- Added Token Ring specific procedures supplied by Acee Lindem and
added him as an author.
- Tightened up terminology and definitions and made appropriate
changes in the text.
Changes from <draft-ietf-vrrp-spec-02.txt> Changes from <draft-ietf-vrrp-spec-02.txt>
- Updated text and references to point to "The Use of HMAC-MD5-96 - Updated text and references to point to "The Use of HMAC-MD5-96
within ESP and AH" that is the correct reference for the use of within ESP and AH" that is the correct reference for the use of
IPSEC AH with MD5. IPSEC AH with MD5.
Changes from <draft-ietf-vrrp-spec-01.txt> Changes from <draft-ietf-vrrp-spec-01.txt>
Major change to use real IP addresses instead of virtual IP Major change to use real IP addresses instead of virtual IP
addresses. Changes include: addresses. Changes include:
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/