--- 1/draft-ietf-vrrp-spec-v2-03.txt 2006-02-05 02:09:53.000000000 +0100 +++ 2/draft-ietf-vrrp-spec-v2-04.txt 2006-02-05 02:09:53.000000000 +0100 @@ -1,28 +1,28 @@ INTERNET-DRAFT S. Knight -June 17, 1999 D. Weaver +October 20, 1999 D. Weaver Ascend Communications, Inc. D. Whipple Microsoft, Inc. R. Hinden D. Mitzel P. Hunt Nokia P. Higginson M. Shand Digital Equipment Corp. A. Lindem IBM Corporation 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. @@ -31,21 +31,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This internet draft expires on December 17, 1999. + This internet draft expires on April 20, 2000. 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 @@ -80,24 +80,25 @@ 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 10.1 No Authentication....................................26 10.2 Simple Text Password.................................26 10.3 IP Authentication Header.............................27 - 11. Acknowledgments...........................................28 - 12. References................................................28 - 13. Authors' Addresses........................................29 - 14. Changes from RFC2338......................................31 + 11. Intellectual Property.....................................28 + 12. Acknowledgments...........................................28 + 13. References................................................28 + 14. Authors' Addresses........................................29 + 15. Changes from RFC2338......................................32 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. @@ -1158,28 +1159,55 @@ configuration errors, replay attacks, and packet corruption/modification. This type of authentication is RECOMMENDED when there is limited control over the administration of nodes on a LAN. While this type of authentication does protect the operation of VRRP, there are other types of attacks that may be employed on shared media links (e.g., generation of bogus ARP replies) that are independent from VRRP and 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 Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve Bellovin, Thomas Narten, Rob Montgomery, and Rob Coltun for their comments and suggestions. -12. References +13. References [802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std 802.1D, 1993 edition. [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, November 1998. [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the Internet Checksum", RFC1071, September 1988. @@ -1195,46 +1223,45 @@ [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby Router Protocol (HSRP)", RFC2281, March 1998. [IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to Provide Fast Failover in IP Networks", Digital Technical Journal, Volume 9 Number 3, Winter 1997. [IPX] Novell Incorporated., "IPX Router Specification", Version 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 1998. [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area Networks", RFC1469, June 1993. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, BCP00009, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, BCP0014, March 1997. [TKARCH] IBM Token-Ring Network, Architecture Reference, Publication SC30-3374-02, Third Edition, (September, 1989). -13. Author's Addresses +14. Author's Addresses Steven Knight Phone: +1 612 943-8990 Ascend Communications EMail: Steven.Knight@ascend.com High Performance Network Division 10250 Valley View Road, Suite 113 Eden Prairie, MN USA 55344 USA - Douglas Weaver Phone: +1 612 943-8990 Ascend Communications EMail: Doug.Weaver@ascend.com High Performance Network Division 10250 Valley View Road, Suite 113 Eden Prairie, MN USA 55344 USA David Whipple Phone: +1 206 703-3876 Microsoft Corporation EMail: dwhipple@microsoft.com One Microsoft Way