draft-ietf-vrrp-spec-04.txt   draft-ietf-vrrp-spec-05.txt 
INTERNET-DRAFT S. Knight INTERNET-DRAFT S. Knight
November 21, 1997 D. Weaver February 2, 1998 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. Nokia
P. Higginson P. Higginson
M. Shand M. Shand
Digital Equipment Corp. Digital Equipment Corp.
Acee Lindem Acee Lindem
IBM Corporation IBM Corporation
Virtual Router Redundancy Protocol Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-04.txt> <draft-ietf-vrrp-spec-05.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 May 21, 1998. This internet draft expires on August 2, 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 assigns VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a responsibility for a virtual router to one of the VRRP routers on a
LAN. The VRRP router controlling the IP address(es) associated with LAN. The VRRP router controlling the IP address(es) associated with
a virtual router is called the Master, and forwards packets sent to a virtual router is called the Master, and forwards packets sent to
these IP addresses. The election process provides dynamic fail over these IP addresses. The election process provides dynamic fail over
in the forwarding responsibility should the Master become in the forwarding responsibility should the Master become
skipping to change at page 2, line 38 skipping to change at page 2, line 38
7. Sending and Receiving VRRP Packets........................19 7. Sending and Receiving VRRP Packets........................19
7.1 Receiving VRRP Packets................................19 7.1 Receiving VRRP Packets................................19
7.2 Transmitting Packets..................................19 7.2 Transmitting Packets..................................19
7.3 Virtual MAC Address...................................20 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
9.1 Operation over FDDI...................................21 9.1 Operation over FDDI...................................21
9.2 Operation over Token Ring.............................21 9.2 Operation over Token Ring.............................22
10. Security Considerations...................................24 10. Security Considerations...................................24
10.1 No Authentication....................................24 10.1 No Authentication....................................24
10.2 Simple Text Password.................................24 10.2 Simple Text Password.................................24
10.3 IP Authentication Header.............................25 10.3 IP Authentication Header.............................25
11. Acknowledgments...........................................25 11. Acknowledgments...........................................25
12. References................................................26 12. References................................................26
13. Authors' Addresses........................................27 13. Authors' Addresses........................................27
14. Changes from Previous Drafts..............................29 14. Changes from Previous Drafts..............................29
1. Introduction 1. Introduction
skipping to change at page 3, line 51 skipping to change at page 3, line 51
process provides dynamic fail-over in the forwarding responsibility process provides dynamic fail-over in the forwarding responsibility
should the Master become unavailable. Any of the virtual router's IP should the Master become unavailable. Any of the virtual router's IP
addresses on a LAN can then be used as the default first hop router addresses on a LAN can then be used as the default first hop router
by end-hosts. The advantage gained from using VRRP is a higher by end-hosts. The advantage gained from using VRRP is a higher
availability default path without requiring configuration of dynamic availability default path without requiring configuration of dynamic
routing or router discovery protocols on every end-host. 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 [IPSTB].
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
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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
VRRP Router A router running the Virtual Router Redundancy VRRP Router A router running the Virtual Router Redundancy
Protocol. It may participate in one or more Protocol. It may participate in one or more
virtual routers. virtual routers.
Virtual Router A Virtual Router Identifier with a set of Virtual Router An abstract object managed by VRRP that acts
associated IP address(es) across a common LAN. as a default router for hosts on a shared LAN.
This is the abstract object that is managed by It consists of a Virtual Router Identifier and
Virtual Router Redundancy Protocol. A VRRP a set of associated IP address(es) across a
router may backup one or more virtual routers. common LAN. A VRRP Router may backup one or
more virtual routers.
IP Address Owner The router that has the IP address(es) as real IP Address Owner The VRRP router that has the virtual router's
interface address(es). This is the router IP address(es) as real interface address(es).
that, when up, will respond to packets This is the router that, when up, will respond
addressed to one of these IP addresses for to packets addressed to one of these IP
ICMP pings, TCP connections, etc. 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 algorithm is to always select the first
address. VRRP advertisements are always sent address. VRRP advertisements are always sent
using the primary IP address as the source of using the primary IP address as the source of
the IP packet. the IP packet.
Virtual Router Master The VRRP router that is assuming the Virtual Router Master The VRRP router that is assuming the
responsibility of forwarding packets sent to responsibility of forwarding packets sent to
skipping to change at page 7, line 26 skipping to change at page 7, line 26
and addresses must be coordinated among all VRRP routers on a LAN. and addresses must be coordinated among all VRRP routers on a LAN.
However, there is no restriction against reusing a VRID with a However, there is no restriction against reusing a VRID with a
different address mapping on different LANs. The scope of each different address mapping on different LANs. The scope of each
virtual router is restricted to a single LAN. virtual router is restricted to a single LAN.
To minimize network traffic, only the Master for each virtual router To minimize network traffic, only the Master for each virtual router
sends periodic VRRP Advertisement messages. A Backup router will not sends periodic VRRP Advertisement messages. A Backup router will not
attempt to pre-empt the Master unless it has higher priority. This attempt to pre-empt the Master unless it has higher priority. This
eliminates service disruption unless a more preferred path becomes eliminates service disruption unless a more preferred path becomes
available. It's also possible to administratively prohibit all pre- available. It's also possible to administratively prohibit all pre-
emption attempts. The only exception is a VRRP router will always emption attempts. The only exception is that a VRRP router will
become Master of any virtual router associated with addresses it always become Master of any virtual router associated with addresses
owns. If the Master becomes unavailable then the highest priority it owns. If the Master becomes unavailable then the highest priority
Backup will transition to Master after a short delay, providing a Backup will transition to Master after a short delay, providing a
controlled transition of the virtual router responsibility with controlled transition of the virtual router responsibility with
minimal service interruption. 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
skipping to change at page 8, line 17 skipping to change at page 8, line 17
router is infrequent, and the expected duration in Master election router is infrequent, and the expected duration in Master election
convergence is quite small ( << 1 second ). Thus the VRRP convergence is quite small ( << 1 second ). Thus the VRRP
optimizations represent significant simplifications in the protocol optimizations represent significant simplifications in the protocol
design while incurring an insignificant probability of brief network design while incurring an insignificant probability of brief network
degradation. degradation.
4. Sample Configurations 4. Sample Configurations
4.1 Sample Configuration 1 4.1 Sample Configuration 1
The following figure shows a simple network with two virtual routers. The following figure shows a simple network with two VRRP routers
implementing one virtual router. Note that this example is provided
to help understand the protocol, but is not expected to occur in
actual practice.
VRID=1 VRID=2
+-----+ +-----+ +-----+ +-----+
| MR1 | | MR2 | | MR1 | | BR1 |
| & | | & | | | | |
| BR2 | | BR1 | | | | |
+-----+ +-----+ VRID=1 +-----+ +-----+
IP A ---------->* *<---------- IP B IP A ---------->* *<--------- IP B
| | | |
| | | |
| | | |
------------------+------------+-----+--------+--------+--------+-- ------------------+------------+-----+--------+--------+--------+--
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
(IP A) (IP A) (IP A) (IP A) (IP A) (IP A) (IP A) (IP A)
| | | | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 | | H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+
Legend: Legend:
---+---+---+-- = 802 network, Ethernet or FDDI ---+---+---+-- = Ethernet, Token Ring, 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 very 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 virtual router #1 (IP A) and the routers run VRRP. The address of virtual router #1 (IP A) and both routers run VRRP. The
router on the left becomes the Master for virtual router #1 (VRID=1) router on the left becomes the Master for virtual router #1 (VRID=1)
and the router on the right becomes the Master for virtual router # 2 and the router on the right is the Backup for virtual router #1. If
(VRID=2). Each router also backs up the other router. If the router the router on the left should fail, the other router will take over
on the left should fail, the other router will take over virtual virtual router #1 and its IP addresses, and provide uninterrupted
router #1 and its IP addresses, and provide uninterrupted service for service for the hosts.
the hosts.
Note that in this example, IP B is not backed up by the router on the
left. IP B is only used by the router on the right as its interface
address. In order to backup IP B, a second virtual router would have
to be configured. This is shown in the next section.
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 spitting their traffic between them. with the hosts spitting their traffic between them. This example is
expected to be very common in actual practice.
VRID=1 VRID=2
+-----+ +-----+ +-----+ +-----+
| MR1 | | MR2 | | MR1 | | MR2 |
| & | | & | | & | | & |
| BR2 | | BR1 | | BR2 | | BR1 |
+-----+ +-----+ VRID=1 +-----+ +-----+ VRID=2
IP A ---------->* *<---------- IP B IP A ---------->* *<---------- IP B
| | | |
| | | |
| | | |
------------------+------------+-----+--------+--------+--------+-- ------------------+------------+-----+--------+--------+--------+--
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
(IP A) (IP A) (IP B) (IP B) (IP A) (IP A) (IP B) (IP B)
| | | | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 | | H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+
Legend: Legend:
---+---+---+-- = 802 network, Ethernet or FDDI ---+---+---+-- = Ethernet, Token Ring, 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,
skipping to change at page 20, line 17 skipping to change at page 20, line 17
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:
00-00-5E-XX-XX-{VRID} (in hex in internet standard bit-order) 00-00-5E-00-01-{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 (00-01) indicate the address block assigned to the VRRP
assigned to the VRRP protocol. {VRID} is the VRRP Virtual Router protocol. {VRID} is the VRRP Virtual Router Identifier. This
Identifier. This mapping provides for up to 255 VRRP routers on a mapping provides for up to 255 VRRP routers on a network.
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.
The IP source address of an ICMP redirect should be the address the The IP source address of an ICMP redirect should be the address the
skipping to change at page 24, line 8 skipping to change at page 24, line 8
bridge segments and there are host implementations which keep their bridge segments and there are host implementations which keep their
source-route information in the ARP cache and do not listen to source-route information in the ARP cache and do not listen to
gratuitous ARPs, these hosts will not update their ARP source-route gratuitous ARPs, these hosts will not update their ARP source-route
information correctly when a switch-over occurs. The only possible information correctly when a switch-over occurs. The only possible
solution is to put all routers with the same VRID on the same source- 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 bridge segment and use techniques to prevent that bridge segment from
being a single point of failure. These techniques are beyond the being a single point of failure. These techniques are beyond the
scope this document. scope this document.
For both the multicast and unicast mode of operation, VRRP For both the multicast and unicast mode of operation, VRRP
advertisements sent to 224.0.0.TBD should be encapsulated as advertisements sent to 224.0.0.18 should be encapsulated as described
described in [RFC1469]. 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 26, line 24 skipping to change at page 26, line 24
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-01.txt>,
June 1997. October 1997.
[IPSTB] Higginson, P., 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 [IPX] Novell Incorporated., "IPX Router Specification", Version
1.10, October 1992. 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 [RFC1469] Pusateri, T., "IP over Token Ring LANs", RFC 1469, June
skipping to change at page 27, line 28 skipping to change at page 27, line 28
Eden Prairie, MN USA 55344 Eden Prairie, MN USA 55344
USA USA
David Whipple Phone: +1 206 703-3876 David Whipple Phone: +1 206 703-3876
Microsoft Corporation EMail: dwhipple@microsoft.com Microsoft Corporation EMail: dwhipple@microsoft.com
One Microsoft Way One Microsoft Way
Redmond, WA USA 98052-6399 Redmond, WA USA 98052-6399
USA USA
Robert Hinden Phone: +1 408 990-2004 Robert Hinden Phone: +1 408 990-2004
Ipsilon Networks, Inc. EMail: hinden@ipsilon.com Nokia EMail: hinden@ipsilon.com
232 Java Drive 232 Java Drive
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Danny Mitzel Phone: +1 408 990-2037 Danny Mitzel Phone: +1 408 990-2037
Ipsilon Networks, Inc. EMail: mitzel@ipsilon.com Nokia EMail: mitzel@ipsilon.com
232 Java Drive 232 Java Drive
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 Nokia 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
Digital Equipment Corp. EMail: higginson@mail.dec.com Digital Equipment Corp. EMail: higginson@mail.dec.com
Digital Park Digital Park
Imperial Way Imperial Way
Reading Reading
Berkshire Berkshire
skipping to change at page 29, line 7 skipping to change at page 29, line 7
UK UK
Acee Lindem Phone: 1-919-254-1805 Acee Lindem Phone: 1-919-254-1805
IBM Corporation E-Mail: acee@raleigh.ibm.com IBM Corporation E-Mail: acee@raleigh.ibm.com
P.O. Box 12195 P.O. Box 12195
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
14. Changes from Previous Drafts 14. Changes from Previous Drafts
Changes from <draft-ietf-vrrp-spec-04.txt>
- Added IANA assignment for MAC prefix.
- Clarified examples and definitions.
- Updated reference to Digital IP Standby protocol.
Changes from <draft-ietf-vrrp-spec-03.txt> Changes from <draft-ietf-vrrp-spec-03.txt>
- Added IANA assignments for protocol and multicast address. MAC - Added IANA assignments for protocol and multicast address. MAC
prefix still needed. prefix still needed.
- Added Token Ring specific procedures supplied by Acee Lindem and - Added Token Ring specific procedures supplied by Acee Lindem and
added him as an author. added him as an author.
- Tightened up terminology and definitions and made appropriate - Tightened up terminology and definitions and made appropriate
changes in the text. changes in the text.
Changes from <draft-ietf-vrrp-spec-02.txt> Changes from <draft-ietf-vrrp-spec-02.txt>
 End of changes. 

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