draft-ietf-vrrp-spec-v2-08.txt   draft-ietf-vrrp-spec-v2-09.txt 
INTERNET-DRAFT R. Hinden INTERNET-DRAFT R. Hinden, Editor
June 29, 2003 P. Hunt August 13, 2003 Nokia
Nokia
D. Mitzel
Tahoe
P. Higginson
M. Shand
Cisco
A. Lindem
Redback
S. Knight
Ascend
D. Weaver
PowerWAN
D. Whipple
Microsoft
Virtual Router Redundancy Protocol Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-v2-08.txt> <draft-ietf-vrrp-spec-v2-09.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 January 4, 2004. This internet draft expires on February 17, 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 3, line 7 skipping to change at page 2, line 7
the LAN to be used as the default first hop router by end-hosts. The the LAN to be used as the default first hop router by end-hosts. The
advantage gained from using VRRP is a higher availability default advantage gained from using VRRP is a higher availability default
path without requiring configuration of dynamic routing or router path without requiring configuration of dynamic routing or router
discovery protocols on every end-host. discovery protocols on every end-host.
This document replaces RFC2338 "Virtual Router Redundancy Protocol". This document replaces RFC2338 "Virtual Router Redundancy Protocol".
RFC2338 will become historic. RFC2338 will become historic.
Table of Contents Table of Contents
1. Introduction...............................................4 1. Introduction...............................................3
2. Required Features..........................................6 2. Required Features..........................................5
3. VRRP Overview..............................................7 3. VRRP Overview..............................................7
4. Sample Configurations......................................9 4. Sample Configurations......................................9
5. Protocol..................................................11 5. Protocol..................................................12
5.1 VRRP Packet Format....................................11 5.1 VRRP Packet Format....................................12
5.2 IP Field Descriptions.................................12 5.2 IP Field Descriptions.................................12
5.3 VRRP Field Descriptions...............................12 5.3 VRRP Field Descriptions...............................13
6. Protocol State Machine....................................14 6. Protocol State Machine....................................16
6.1 Parameters per Virtual Router.........................14 6.1 Parameters per Virtual Router.........................16
6.2 Timers................................................16 6.2 Timers................................................17
6.3 State Transition Diagram..............................16 6.3 State Transition Diagram..............................17
6.4 State Descriptions....................................16 6.4 State Descriptions....................................17
7. Sending and Receiving VRRP Packets........................20 7. Sending and Receiving VRRP Packets........................21
7.1 Receiving VRRP Packets................................20 7.1 Receiving VRRP Packets................................21
7.2 Transmitting Packets..................................20 7.2 Transmitting Packets..................................21
7.3 Virtual MAC Address...................................21 7.3 Virtual MAC Address...................................22
8. Operational Issues........................................22 8. Operational Issues........................................23
8.1 ICMP Redirects........................................22 8.1 ICMP Redirects........................................23
8.2 Host ARP Requests.....................................22 8.2 Host ARP Requests.....................................23
8.3 Proxy ARP.............................................22 8.3 Proxy ARP.............................................23
8.4 Potential Forwarding Loop.............................23 8.4 Potential Forwarding Loop.............................24
9. Operation over FDDI, Token Ring, and ATM LANE.............23 9. Operation over FDDI, Token Ring, and ATM LANE.............24
9.1 Operation over FDDI...................................23 9.1 Operation over FDDI...................................24
9.2 Operation over Token Ring.............................23 9.2 Operation over Token Ring.............................24
9.3 Operation over ATM LANE...............................25 9.3 Operation over ATM LANE...............................26
10. Security Considerations...................................26 10. Security Considerations...................................27
11. Intellectual Property.....................................26 11. Intellectual Property.....................................27
12. Acknowledgments...........................................27 12. Acknowledgments...........................................28
13. Normative References......................................27 13. Normative References......................................28
14. Informative References....................................28 14. Informative References....................................29
15. Authors' Addresses........................................28 15. Editors' Address..........................................29
16. Changes from RFC2338......................................31 16. Changes from RFC2338......................................30
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 5, line 16 skipping to change at page 4, line 16
"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].
The IESG/IETF take no position regarding the validity or scope of any The IESG/IETF take no position regarding the validity or scope of any
intellectual property right or other rights that might be claimed to intellectual property right or other rights that might be claimed to
pertain to the implementation or use of the technology, or the extent pertain to the implementation or use of the technology, or the extent
to which any license under such rights might or might not be to which any license under such rights might or might not be
available. See the IETF IPR web page at http://www.ietf.org/ipr.html available. See the IETF IPR web page at http://www.ietf.org/ipr.html
for additional information. for additional information.
1.1 Scope 1.1 Contributors
The following people, who are the authors of the RFC2338 that this
document is based on and replaces, contributed to the text in this
document. They are P. Higginson, R. Hinden, P. Hunt, S. Knight, A.
Lindem, D. Mitzel, M. Shand, D. Weaver, and D. Whipple. They are not
listed as authors of the document due to currnet RFC-Editor policies.
1.2 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 Virtual Router Master are presented. Finally, operational single Virtual Router Master are presented. Finally, operational
issues related to MAC address mapping, handling of ARP requests, issues related to MAC address mapping, handling of ARP requests,
generation of ICMP redirect messages, and security issues are generation of ICMP redirect messages, and security issues are
addressed. 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.3 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 An abstract object managed by VRRP that acts Virtual Router An abstract object managed by VRRP that acts
as a default router for hosts on a shared LAN. as a default router for hosts on a shared LAN.
It consists of a Virtual Router Identifier and It consists of a Virtual Router Identifier and
a set of associated IP address(es) across a a set of associated IP address(es) across a
common LAN. A VRRP Router may backup one or common LAN. A VRRP Router may backup one or
skipping to change at page 26, line 13 skipping to change at page 27, line 13
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 due 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 due 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
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.
skipping to change at page 28, line 18 skipping to change at page 29, line 18
September 1991. September 1991.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC2131,
March 1997. March 1997.
[OSPF] Moy, J., "OSPF version 2", RFC2328, 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.
15. Author's Addresses 15. Editor's Address
P. Higginson
Digital Equipment Corp.
Digital Park
Imperial Way
Reading
Berkshire
RG2 0TE
UK
Phone: +44 118 920 6293
Email: higginson@mail.dec.com
Robert Hinden Robert Hinden
Nokia Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
US US
Phone: +1 650 625-2004 Phone: +1 650 625-2004
Email: hinden@iprg.nokia.com Email: hinden@iprg.nokia.com
Peter Hunt
Nokia
313 Fairchild Drive
Mountain View, CA 94043
US
Phone: +1 650 625-2093
Email: hunt@iprg.nokia.com
Steven Knight
Ascend Communications
High Performance Network Division
10250 Valley View Road, Suite 113
Eden Prairie, MN USA 55344
US
Phone: +1 612 943-8990
Email: Steven.Knight@ascend.com
Acee Lindem
Redback Networks
102 Carric Bend Court
Apex, NC 27502 USA
US
Email: acee@redback.com
Danny J. Mitzel
Tahoe Networks
3052 Orchard Drive
San Jose, CA 95134
US
Phone: +1 408 944 8611
Email: mitzel@tahoenetworks.com
Mike Shand
Cisco Systems
Reading - Green Park 250
250 Longwater Avenue
Reading
BERKSHIRE
United Kingdom
RG2 6GB
Phone: +44 (0)20 8824-8690
Email: mshand@cisco.com
Douglas Weaver
PowerWAN, Inc.
6595 Edenvale Blvd, Suite 180
Eden Prairie, MN 55346
US
Phone: +1 952 937-0056
Email: dweaver@powerwan.com
David Whipple
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
US
Phone: +1 206 703-3876
Email: dwhipple@microsoft.com
16. Changes from RFC2338 16. Changes from RFC2338
- Moved authors of RFC2338 to new Contributers section to comply
with RFC editor policy and listed R. Hinden as Editor.
- Removed authentication methods from VRRP. Changes included: - Removed authentication methods from VRRP. Changes included:
o Removed the values for password and IPSEC based authentication. o Removed the values for password and IPSEC based authentication.
The fields and values are retained to keep backwards The fields and values are retained to keep backwards
compatibility with RFC2338. compatibility with RFC2338.
o Removed section on extensible security o Removed section on extensible security
o Updated security consideration section to remove discussion of o Updated security consideration section to remove discussion of
different authentication methods and added new text explaining different authentication methods and added new text explaining
motivation for change. motivation for change.
- Revised the section 4 examples text with a clearer description of - Revised the section 4 examples text with a clearer description of
mapping of IP address owner, priorities, etc. mapping of IP address owner, priorities, etc.
 End of changes. 

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