draft-ietf-vrrp-spec-v2-07.txt   draft-ietf-vrrp-spec-v2-08.txt 
INTERNET-DRAFT R. Hinden INTERNET-DRAFT R. Hinden
May 20, 2003 P. Hunt June 29, 2003 P. Hunt
Nokia Nokia
D. Mitzel D. Mitzel
Tahoe Tahoe
P. Higginson P. Higginson
M. Shand M. Shand
Cisco Cisco
A. Lindem A. Lindem
Redback Redback
S. Knight S. Knight
Ascend Ascend
D. Weaver D. Weaver
PowerWAN PowerWAN
D. Whipple D. Whipple
Microsoft Microsoft
Virtual Router Redundancy Protocol Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-v2-07.txt> <draft-ietf-vrrp-spec-v2-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. 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 view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This internet draft expires on November 20, 2003. This internet draft expires on January 4, 2004.
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 24, line 18 skipping to change at page 24, line 18
collide with other usage of the same token ring functional collide with other usage of the same token ring functional
addresses. addresses.
Due to these difficulties, the preferred mode of operation over token Due to these difficulties, the preferred mode of operation over token
ring will be to use a token ring functional address for the VRID ring will be to use a token ring functional address for the VRID
virtual MAC address. Token ring functional addresses have the two virtual MAC address. Token ring functional addresses have the two
high order bits in the first MAC address octet set to B'1'. They 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). 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 However, unlike multicast addresses, there is only one unique
functional address per bit position. The functional addresses functional address per bit position. The functional addresses
addresses 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by the Token
by the Token Ring Architecture [TKARCH] for user-defined Ring Architecture [TKARCH] for user-defined applications. However,
applications. However, since there are only 12 user-defined token since there are only 12 user-defined token ring functional addresses,
ring functional addresses, there may be other non-IP protocols using there may be other non-IP protocols using the same functional
the same functional address. Since the Novell IPX [IPX] protocol uses address. Since the Novell IPX [IPX] protocol uses the
the 03-00-00-10-00-00 functional address, operation of VRRP over 03-00-00-10-00-00 functional address, operation of VRRP over token
token ring will avoid use of this functional address. In general, ring will avoid use of this functional address. In general, token
token ring VRRP users will be responsible for resolution of other ring VRRP users will be responsible for resolution of other user-
user-defined token ring functional address conflicts. defined token ring functional address conflicts.
VRIDs are mapped directly to token ring functional addresses. In VRIDs are mapped directly to token ring functional addresses. In
order to decrease the likelihood of functional address conflicts, order to decrease the likelihood of functional address conflicts,
allocation will begin with the largest functional address. Most non- allocation will begin with the largest functional address. Most non-
IP protocols use the first or first couple user-defined functional IP protocols use the first or first couple user-defined functional
addresses and it is expected that VRRP users will choose VRIDs addresses and it is expected that VRRP users will choose VRIDs
sequentially starting with 1. sequentially starting with 1.
VRID Token Ring Functional Address VRID Token Ring Functional Address
---- ----------------------------- ---- -----------------------------
skipping to change at page 25, line 24 skipping to change at page 25, line 24
Additionally, routers MAY support unicast mode of operation to take Additionally, routers MAY support unicast mode of operation to take
advantage of newer token ring adapter implementations that support advantage of newer token ring adapter implementations that support
non-promiscuous reception for multiple unicast MAC addresses and to non-promiscuous reception for multiple unicast MAC addresses and to
avoid both the multicast traffic and usage conflicts associated with avoid both the multicast traffic and usage conflicts associated with
the use of token ring functional addresses. Unicast mode uses the the use of token ring functional addresses. Unicast mode uses the
same mapping of VRIDs to virtual MAC addresses as Ethernet. However, same mapping of VRIDs to virtual MAC addresses as Ethernet. However,
one important difference exists. ARP request/reply packets contain one important difference exists. ARP request/reply packets contain
the virtual MAC address as the source MAC address. The reason for the virtual MAC address as the source MAC address. The reason for
this is that some token ring driver implementations keep a cache of this is that some token ring driver implementations keep a cache of
MAC address/source routing information independent of the ARP cache. MAC address/source routing information independent of the ARP cache.
Hence, these implementations need have to receive a packet with the Hence, these implementations need to receive a packet with the
virtual MAC address as the source address in order to transmit to virtual MAC address as the source address in order to transmit to
that MAC address in a source-route bridged network. that MAC address in a source-route bridged network.
Unicast mode on token ring has one limitation that should be Unicast mode on token ring has one limitation that should be
considered. If there are VRID routers on different source-route considered. If there are VRID routers on different source-route
bridge segments and there are host implementations that keep their bridge segments and there are host implementations that 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-
skipping to change at page 26, line 11 skipping to change at page 26, line 11
Operation of VRRP over ATM LANE on routers with ATM LANE interfaces Operation of VRRP over ATM LANE on routers with ATM LANE interfaces
and/or routers behind proxy LEC's are beyond the scope of this and/or routers behind proxy LEC's are beyond the scope of this
document. document.
10. Security Considerations 10. Security Considerations
VRRP does not currently include any type of authentication. Earlier VRRP does not currently include any type of authentication. Earlier
versions of the VRRP specification included several types of versions of the VRRP specification included several types of
authentication ranging from none to strong. Operational experience authentication ranging from none to strong. Operational experience
and further analysis determined that these did not provide any real and further analysis determined that these did not provide any real
measure of security and do to the nature of the VRRP protocol they measure of security and due to the nature of the VRRP protocol they
did not prevent incorrectly configured or hostile routers from did not prevent incorrectly configured or hostile routers from
becoming VRRP masters. In general do to the nature of LANs, any becoming VRRP masters. In general do to the nature of LANs, any
device on the LAN has the ability to disrupt all communication. device on the LAN has the ability to disrupt all communication.
Consequentially it was determined it was better to remove the Consequentially it was determined it was better to remove the
additional authentication methods in this specification of the VRRP additional authentication methods in this specification of the VRRP
protocol as it did not provide the authentication originally protocol as it did not provide the authentication originally
intended. intended.
Independent of any authentication type VRRP includes a mechanism Independent of any authentication type VRRP includes a mechanism
(setting TTL=255, checking on receipt) that protects against VRRP (setting TTL=255, checking on receipt) that protects against VRRP
skipping to change at page 27, line 14 skipping to change at page 27, line 14
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
12. Acknowledgments 12. 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, Steve
Bellovin, Thomas Narten, Rob Montgomery, and Rob Coltun for their Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, and Radia
comments and suggestions. Perlman for their comments and suggestions.
13. Normative References 13. Normative References
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std [802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std
802.1D, 1993 edition. 802.1D, 1993 edition.
[CKSM] Braden, R., D. Borman, C. Partridge, "Computing the [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the
Internet Checksum", RFC1071, September 1988. Internet Checksum", RFC1071, September 1988.
[HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby
 End of changes. 

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