draft-ietf-vrrp-spec-v2-03.txt   draft-ietf-vrrp-spec-v2-04.txt 
INTERNET-DRAFT S. Knight INTERNET-DRAFT S. Knight
June 17, 1999 D. Weaver October 20, 1999 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
Nokia Nokia
P. Higginson P. Higginson
M. Shand M. Shand
Digital Equipment Corp. Digital Equipment Corp.
A. Lindem A. Lindem
IBM Corporation IBM Corporation
Virtual Router Redundancy Protocol Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-v2-03.txt> <draft-ietf-vrrp-spec-v2-04.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.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This internet draft expires on December 17, 1999. This internet draft expires on April 20, 2000.
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 45 skipping to change at page 2, line 45
8.3 Proxy ARP.............................................22 8.3 Proxy ARP.............................................22
8.4 Potential Forwarding Loop.............................23 8.4 Potential Forwarding Loop.............................23
9. Operation over FDDI, Token Ring, and ATM LANE.............23 9. Operation over FDDI, Token Ring, and ATM LANE.............23
9.1 Operation over FDDI...................................23 9.1 Operation over FDDI...................................23
9.2 Operation over Token Ring.............................23 9.2 Operation over Token Ring.............................23
9.3 Operation over ATM LANE...............................25 9.3 Operation over ATM LANE...............................25
10. Security Considerations...................................26 10. Security Considerations...................................26
10.1 No Authentication....................................26 10.1 No Authentication....................................26
10.2 Simple Text Password.................................26 10.2 Simple Text Password.................................26
10.3 IP Authentication Header.............................27 10.3 IP Authentication Header.............................27
11. Acknowledgments...........................................28 11. Intellectual Property.....................................28
12. References................................................28 12. Acknowledgments...........................................28
13. Authors' Addresses........................................29 13. References................................................28
14. Changes from RFC2338......................................31 14. Authors' Addresses........................................29
15. Changes from RFC2338......................................32
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 28, line 5 skipping to change at page 28, line 5
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 a LAN. While this type control over the administration of nodes on a LAN. While this type
of authentication does protect the operation of VRRP, there are other of authentication does protect the operation of VRRP, there are other
types of attacks that may be employed on shared media links (e.g., types of attacks that may be employed on shared media links (e.g.,
generation of bogus ARP replies) that are independent from VRRP and generation of bogus ARP replies) that are independent from VRRP and
are not protected. are not protected.
11. Acknowledgments 11. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
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, and Rob Coltun for their
comments and suggestions. comments and suggestions.
12. References 13. 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.
[AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402,
November 1998. November 1998.
[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.
skipping to change at page 28, line 42 skipping to change at page 29, line 24
[HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby
Router Protocol (HSRP)", RFC2281, March 1998. Router Protocol (HSRP)", RFC2281, March 1998.
[IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to [IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to
Provide Fast Failover in IP Networks", Digital Technical Provide Fast Failover in IP Networks", Digital Technical
Journal, Volume 9 Number 3, Winter 1997. 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", RFC2338, STD0054, April 1998. [OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998.
[RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November [RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November
1998. 1998.
[RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area
Networks", RFC1469, June 1993. Networks", RFC1469, June 1993.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC2026, BCP00009, October 1996. 3", RFC2026, BCP00009, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP0014, March 1997. Requirement Levels", RFC2119, BCP0014, March 1997.
[TKARCH] IBM Token-Ring Network, Architecture Reference, Publication [TKARCH] IBM Token-Ring Network, Architecture Reference, Publication
SC30-3374-02, Third Edition, (September, 1989). SC30-3374-02, Third Edition, (September, 1989).
13. Author's Addresses 14. 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
Ascend Communications EMail: Doug.Weaver@ascend.com Ascend Communications EMail: Doug.Weaver@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
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
 End of changes. 

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