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 37		skipping to change at page 12, line 37
	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.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/