--- 1/draft-ietf-vrrp-spec-v2-08.txt 2006-02-05 02:09:57.000000000 +0100 +++ 2/draft-ietf-vrrp-spec-v2-09.txt 2006-02-05 02:09:57.000000000 +0100 @@ -1,51 +1,37 @@ -INTERNET-DRAFT R. Hinden -June 29, 2003 P. Hunt - Nokia - D. Mitzel - Tahoe - P. Higginson - M. Shand - Cisco - A. Lindem - Redback - S. Knight - Ascend - D. Weaver - PowerWAN - D. Whipple - Microsoft +INTERNET-DRAFT R. Hinden, Editor +August 13, 2003 Nokia Virtual Router Redundancy Protocol - + Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. - This internet draft expires on January 4, 2004. + This internet draft expires on February 17, 2004. Abstract This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become @@ -53,53 +39,53 @@ 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 path without requiring configuration of dynamic routing or router discovery protocols on every end-host. This document replaces RFC2338 "Virtual Router Redundancy Protocol". RFC2338 will become historic. Table of Contents - 1. Introduction...............................................4 - 2. Required Features..........................................6 + 1. Introduction...............................................3 + 2. Required Features..........................................5 3. VRRP Overview..............................................7 4. Sample Configurations......................................9 - 5. Protocol..................................................11 - 5.1 VRRP Packet Format....................................11 + 5. Protocol..................................................12 + 5.1 VRRP Packet Format....................................12 5.2 IP Field Descriptions.................................12 - 5.3 VRRP Field Descriptions...............................12 - 6. Protocol State Machine....................................14 - 6.1 Parameters per Virtual Router.........................14 - 6.2 Timers................................................16 - 6.3 State Transition Diagram..............................16 - 6.4 State Descriptions....................................16 - 7. Sending and Receiving VRRP Packets........................20 - 7.1 Receiving VRRP Packets................................20 - 7.2 Transmitting Packets..................................20 - 7.3 Virtual MAC Address...................................21 - 8. Operational Issues........................................22 - 8.1 ICMP Redirects........................................22 - 8.2 Host ARP Requests.....................................22 - 8.3 Proxy ARP.............................................22 - 8.4 Potential Forwarding Loop.............................23 - 9. Operation over FDDI, Token Ring, and ATM LANE.............23 - 9.1 Operation over FDDI...................................23 - 9.2 Operation over Token Ring.............................23 - 9.3 Operation over ATM LANE...............................25 - 10. Security Considerations...................................26 - 11. Intellectual Property.....................................26 - 12. Acknowledgments...........................................27 - 13. Normative References......................................27 - 14. Informative References....................................28 - 15. Authors' Addresses........................................28 - 16. Changes from RFC2338......................................31 + 5.3 VRRP Field Descriptions...............................13 + 6. Protocol State Machine....................................16 + 6.1 Parameters per Virtual Router.........................16 + 6.2 Timers................................................17 + 6.3 State Transition Diagram..............................17 + 6.4 State Descriptions....................................17 + 7. Sending and Receiving VRRP Packets........................21 + 7.1 Receiving VRRP Packets................................21 + 7.2 Transmitting Packets..................................21 + 7.3 Virtual MAC Address...................................22 + 8. Operational Issues........................................23 + 8.1 ICMP Redirects........................................23 + 8.2 Host ARP Requests.....................................23 + 8.3 Proxy ARP.............................................23 + 8.4 Potential Forwarding Loop.............................24 + 9. Operation over FDDI, Token Ring, and ATM LANE.............24 + 9.1 Operation over FDDI...................................24 + 9.2 Operation over Token Ring.............................24 + 9.3 Operation over ATM LANE...............................26 + 10. Security Considerations...................................27 + 11. Intellectual Property.....................................27 + 12. Acknowledgments...........................................28 + 13. Normative References......................................28 + 14. Informative References....................................29 + 15. Editors' Address..........................................29 + 16. Changes from RFC2338......................................30 1. Introduction There are a number of methods that an end-host can use to determine its first hop router towards a particular IP destination. These include running (or snooping) a dynamic routing protocol such as Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running an ICMP router discovery client [DISC] or using a statically configured default route. @@ -146,35 +132,43 @@ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 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, and theory of operation of VRRP. The message formats, protocol processing rules and state machine that guarantee convergence to a single Virtual Router Master are presented. Finally, operational issues related to MAC address mapping, handling of ARP requests, generation of ICMP redirect messages, and security issues are addressed. This protocol is intended for use with IPv4 routers only. A separate specification will be produced if it is decided that similar functionality is desirable in an IPv6 environment. -1.2 Definitions +1.3 Definitions VRRP Router A router running the Virtual Router Redundancy Protocol. It may participate in one or more virtual routers. Virtual Router An abstract object managed by VRRP that acts as a default router for hosts on a shared LAN. It consists of a Virtual Router Identifier and a set of associated IP address(es) across a common LAN. A VRRP Router may backup one or @@ -1076,21 +1066,21 @@ document. 10. Security Considerations VRRP does not currently include any type of authentication. Earlier versions of the VRRP specification included several types of authentication ranging from none to strong. Operational experience and further analysis determined that these did not provide any real measure of security and due to the nature of the VRRP protocol they 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. Consequentially it was determined it was better to remove the additional authentication methods in this specification of the VRRP protocol as it did not provide the authentication originally intended. Independent of any authentication type VRRP includes a mechanism (setting TTL=255, checking on receipt) that protects against VRRP packets being injected from another remote network. This limits most vulnerabilities to local attacks. @@ -1173,100 +1163,35 @@ September 1991. [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, March 1997. [OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998. [RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November 1998. -15. Author's Addresses - - P. Higginson - Digital Equipment Corp. - Digital Park - Imperial Way - Reading - Berkshire - RG2 0TE - UK - Phone: +44 118 920 6293 - Email: higginson@mail.dec.com +15. Editor's Address Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US + Phone: +1 650 625-2004 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 + - 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: o Removed the values for password and IPSEC based authentication. The fields and values are retained to keep backwards compatibility with RFC2338. o Removed section on extensible security o Updated security consideration section to remove discussion of different authentication methods and added new text explaining motivation for change. - Revised the section 4 examples text with a clearer description of mapping of IP address owner, priorities, etc.