< draft-ietf-vrrp-spec-v2-09.txt   draft-ietf-vrrp-spec-v2-10.txt >
INTERNET-DRAFT R. Hinden, Editor INTERNET-DRAFT R. Hinden, Editor
August 13, 2003 Nokia February 4, 2004 Nokia
Virtual Router Redundancy Protocol Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-v2-09.txt> <draft-ietf-vrrp-spec-v2-10.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 February 17, 2004. This internet draft expires on August 9, 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
unavailable. This allows any of the virtual router IP addresses on unavailable. This allows any of the virtual router IP addresses on
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.
Table of Contents Table of Contents
1. Introduction...............................................3 1. Introduction...............................................3
2. Required Features..........................................5 2. Required Features..........................................5
3. VRRP Overview..............................................7 3. VRRP Overview..............................................6
4. Sample Configurations......................................9 4. Sample Configurations......................................8
5. Protocol..................................................12 5. Protocol..................................................11
5.1 VRRP Packet Format....................................12 5.1 VRRP Packet Format....................................11
5.2 IP Field Descriptions.................................12 5.2 IP Field Descriptions.................................11
5.3 VRRP Field Descriptions...............................13 5.3 VRRP Field Descriptions...............................12
6. Protocol State Machine....................................16 6. Protocol State Machine....................................15
6.1 Parameters per Virtual Router.........................16 6.1 Parameters per Virtual Router.........................15
6.2 Timers................................................17 6.2 Timers................................................16
6.3 State Transition Diagram..............................17 6.3 State Transition Diagram..............................16
6.4 State Descriptions....................................17 6.4 State Descriptions....................................16
7. Sending and Receiving VRRP Packets........................21 7. Sending and Receiving VRRP Packets........................20
7.1 Receiving VRRP Packets................................21 7.1 Receiving VRRP Packets................................20
7.2 Transmitting Packets..................................21 7.2 Transmitting Packets..................................20
7.3 Virtual MAC Address...................................22 7.3 Virtual MAC Address...................................21
8. Operational Issues........................................23 8. Operational Issues........................................22
8.1 ICMP Redirects........................................23 8.1 ICMP Redirects........................................22
8.2 Host ARP Requests.....................................23 8.2 Host ARP Requests.....................................22
8.3 Proxy ARP.............................................23 8.3 Proxy ARP.............................................22
8.4 Potential Forwarding Loop.............................24 8.4 Potential Forwarding Loop.............................23
9. Operation over FDDI, Token Ring, and ATM LANE.............24 9. Operation over FDDI, Token Ring, and ATM LANE.............23
9.1 Operation over FDDI...................................24 9.1 Operation over FDDI...................................23
9.2 Operation over Token Ring.............................24 9.2 Operation over Token Ring.............................23
9.3 Operation over ATM LANE...............................26 9.3 Operation over ATM LANE...............................25
10. Security Considerations...................................27 10. Security Considerations...................................26
11. Intellectual Property.....................................27 11. Intellectual Property.....................................26
12. Acknowledgments...........................................28 12. Acknowledgments...........................................27
13. Normative References......................................28 13. Normative References......................................27
14. Informative References....................................29 14. Informative References....................................28
15. Editors' Address..........................................29 15. Editors' Address..........................................28
16. Changes from RFC2338......................................30 16. Changes from RFC2338......................................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 48 skipping to change at page 3, line 48
VRRP routers on a LAN. The VRRP router controlling the IP VRRP routers on a LAN. The VRRP router controlling the IP
address(es) associated with a virtual router is called the Master, address(es) associated with a virtual router is called the Master,
and forwards packets sent to these IP addresses. The election and forwards packets sent to these IP addresses. The election
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 the proprietary protocols "Hot
protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a Standby Router Protocol (HSRP)" [HSRP] and "IP Standby Protocol"
Digital Equipment Corporation, Inc. proprietary protocol named IP [IPSTB].
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].
The IESG/IETF take no position regarding the validity or scope of any
intellectual property right or other rights that might be claimed to
pertain to the implementation or use of the technology, or the extent
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
for additional information.
1.1 Contributors 1.1 Contributors
The following people, who are the authors of the RFC2338 that this 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 is based on and replaces, contributed to the text in this
document. They are P. Higginson, R. Hinden, P. Hunt, S. Knight, A. 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 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. listed as authors of the document due to current RFC-Editor policies.
1.2 Scope 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.
skipping to change at page 6, line 28 skipping to change at page 6, line 22
2.3 Minimization of Unnecessary Service Disruptions 2.3 Minimization of Unnecessary Service Disruptions
Once Master election has been performed then any unnecessary Once Master election has been performed then any unnecessary
transitions between Master and Backup routers can result in a transitions between Master and Backup routers can result in a
disruption in service. The protocol should ensure after Master disruption in service. The protocol should ensure after Master
election that no state transition is triggered by any Backup router election that no state transition is triggered by any Backup router
of equal or lower preference as long as the Master continues to of equal or lower preference as long as the Master continues to
function properly. function properly.
Some environments may find it beneficial to avoid the state Some environments may find it beneficial to avoid the state
transition triggered when a router becomes available that is more transition triggered when a router becomes available that is
preferential than the current Master. It may be useful to support an preferred over the current Master. It may be useful to support an
override of the immediate convergence to the preferred path. override of the immediate convergence to the preferred path.
2.4 Efficient Operation over Extended LANs 2.4 Efficient Operation over Extended LANs
Sending IP packets on a multiaccess LAN requires mapping from an IP Sending IP packets on a multiaccess LAN requires mapping from an IP
address to a MAC address. The use of the virtual router MAC address address to a MAC address. The use of the virtual router MAC address
in an extended LAN employing learning bridges can have a significant in an extended LAN employing learning bridges can have a significant
effect on the bandwidth overhead of packets sent to the virtual effect on the bandwidth overhead of packets sent to the virtual
router. If the virtual router MAC address is never used as the router. If the virtual router MAC address is never used as the
source address in a link level frame then the station location is source address in a link level frame then the station location is
skipping to change at page 13, line 38 skipping to change at page 12, line 38
The type field specifies the type of this VRRP packet. The only The type field specifies the type of this VRRP packet. The only
packet type defined in this version of the protocol is: packet type defined in this version of the protocol is:
1 ADVERTISEMENT 1 ADVERTISEMENT
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. Configurable item in the
range 1-255 (decimal). There is no default.
5.3.4 Priority 5.3.4 Priority
The priority field specifies the sending VRRP router's priority for The priority field specifies the sending VRRP router's priority for
the virtual router. Higher values equal higher priority. This field the virtual router. Higher values equal higher priority. This field
is an 8 bit unsigned integer field. is an 8 bit unsigned integer field.
The priority value for the VRRP 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).
skipping to change at page 16, line 9 skipping to change at page 15, line 9
5.3.10 Authentication Data 5.3.10 Authentication Data
The authentication string is currently only used to maintain The authentication string is currently only used to maintain
backwards compatibility with RFC2338. It SHOULD be set to zero on backwards compatibility with RFC2338. It SHOULD be set to zero on
transmission and ignored on reception. transmission and ignored on reception.
6. Protocol State Machine 6. Protocol State Machine
6.1 Parameters per Virtual Router 6.1 Parameters per Virtual Router
VRID Virtual Router Identifier. Configured item VRID Virtual Router Identifier. Configurable
in the range 1-255 (decimal). There is no item in the range 1-255 (decimal). There is
default. no default.
Priority Priority value to be used by this VRRP Priority Priority value to be used by this VRRP
router in Master election for this virtual router in Master election for this virtual
router. The value of 255 (decimal) is router. The value of 255 (decimal) is
reserved for the router that owns the IP reserved for the router that owns the IP
addresses associated with the virtual addresses associated with the virtual
router. The value of 0 (zero) is reserved router. The value of 0 (zero) is reserved
for Master router to indicate it is for Master router to indicate it is
releasing responsibility for the virtual releasing responsibility for the virtual
router. The range 1-254 (decimal) is router. The range 1-254 (decimal) is
skipping to change at page 27, 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 due to the nature of the VRRP protocol they measure of security. Due to the nature of the VRRP protocol, even if
did not prevent incorrectly configured or hostile routers from VRRP messages are cryptographically protected, it does not prevent
becoming VRRP masters. In general due to the nature of LANs, any hostile routers from behaving as if they are a VRRP master, creating
device on the LAN has the ability to disrupt all communication. multiple masters. Authentication of VRRP messages could have
Consequentially it was determined it was better to remove the prevented a hostile router from causing all properly functioning
additional authentication methods in this specification of the VRRP routers from going into backup state. However, having multiple
protocol as it did not provide the authentication originally masters can cause as much disruption as no routers, which
intended. authentication cannot prevent. Also, even if a hostile router could
not disrupt VRRP, it can disrupt ARP and create the same effect as
having all routers go into backup.
It should be noted that these attacks are not worse and are a subset
of the attacks that any node attached to a LAN can do independently
of VRRP. The kind of attacks a malicious node on a LAN can do
include promiscuously receiving packets for any routers MAC address,
sending packets with the routers MAC address as the source MAC
addresses in the L2 header to tell the L2 switches to send packets
addressed to the router to the malicious node instead of the router,
send redirects to tell the hosts to send their traffic somewhere
else, send unsolicited ARP replies, answer ARP requests, etc., etc.
All of this can be done independently of implementing VRRP. VRRP
does not add to these vulnerabilities.
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.
VRRP does not provide any confidentiality. Confidentiality is not VRRP does not provide any confidentiality. Confidentiality is not
necessary for the correct operation of VRRP and there is no necessary for the correct operation of VRRP and there is no
information in the VRRP messages that must be kept secret from other information in the VRRP messages that must be kept secret from other
nodes on the LAN. nodes on the LAN.
skipping to change at page 27, line 44 skipping to change at page 27, line 10
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances 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 licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat. See the IETF IPR web page at
http://www.ietf.org/ipr.html for additional information.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
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, Rob Coltun, and Radia Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, Radia Perlman,
Perlman for their comments and suggestions. Russ Housley, Harald Alvestrand, Steve Bellovin, Ned Freed, Ted
Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex Zinin 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
skipping to change at page 29, line 27 skipping to change at page 28, line 45
15. Editor's Address 15. Editor's Address
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: bob.hinden@nokia.com
16. Changes from RFC2338 16. Changes from RFC2338
- Moved authors of RFC2338 to new Contributers section to comply - Moved authors of RFC2338 to new Contributers section to comply
with RFC editor policy and listed R. Hinden as Editor. 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 and describe vulnerabilities.
- 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.
- Clarify the section 7.1 text describing address list validation. - Clarify the section 7.1 text describing address list validation.
- Corrected text in Preempt_Mode definition. - Corrected text in Preempt_Mode definition.
- Changed authentication to be per Virtual Router instead of per - Changed authentication to be per Virtual Router instead of per
Interface. Interface.
- Added new subsection (9.3) stating that VRRP over ATM LANE is - Added new subsection (9.3) stating that VRRP over ATM LANE is
beyond the scope of this document. beyond the scope of this document.
- Clarified text describing received packet length check. - Clarified text describing received packet length check.
- Clarified text describing received authentication check. - Clarified text describing received authentication check.
- Clarified text describing VRID verification check. - Clarified text describing VRID verification check.
- Added new subsection (8.4) describing need to not forward packets - Added new subsection (8.4) describing need to not forward packets
for adopted IP addresses. for adopted IP addresses.
- Added clarification to the security considerations section. - Added clarification to the security considerations section.
- Added reference for computing the internet checksum. - Added reference for computing the internet checksum.
- Updated references and author information. - Updated references and author information.
- Changed order of author list based on contribution level. - Various small editorial changes.
 End of changes. 17 change blocks. 
66 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/