convergence, and convergence will fail.   To avoid this an implementation SHOULD configure the virtual router   MAC address by adding a unicast MAC filter in the FDDI device, rather   than changing its hardware MAC address.  This will prevent a Master   router from removing any ADVERTISEMENTS it did not originate.9.2  Operation over Token Ring   Token ring has several characteristics which make running VRRP   difficult. These include:    - In order to switch to a new master located on a different bridge      token ring segment from the previous master when using source      route bridges, a mechanism is required to update cached source      route information.    - No general multicast mechanism supported across old and new token      ring adapter implementations. While many newer token ring adapters      support group addresses, token ring functional address support is      the only generally available multicast mechanism. Due to the      limited number of token ring functional addresses these may      collide with other usage of the same token ring functional      addresses.   Due to these difficulties, the preferred mode of operation over token   ring will be to use a token ring functional address for the VRID   virtual MAC address. Token ring functional addresses have the two   high order bits in the first MAC address octet set to B'1'.  They   range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format).   However, unlike multicast addresses, there is only one unique   functional address per bit position. The functional addresses   addresses  03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved   by the Token Ring Architecture [TKARCH] for user-defined   applications.  However, since there are only 12 user-defined token   ring functional addresses, there may be other non-IP protocols using   the same functional address. Since the Novell IPX [IPX] protocol usesKnight, et. al.             Standards Track                    [Page 21]RFC 2338                          VRRP                        April 1998   the 03-00-00-10-00-00 functional address, operation of VRRP over   token ring will avoid use of this functional address. In general,   token ring VRRP users will be responsible for resolution of other   user-defined token ring functional address conflicts.   VRIDs are mapped directly to token ring functional addresses. In   order to decrease the likelihood of functional address conflicts,   allocation will begin with the largest functional address. Most non-   IP protocols use the first or first couple user-defined functional   addresses and it is expected that VRRP users will choose VRIDs   sequentially starting with 1.   VRID      Token Ring Functional Address   ----      -----------------------------      1             03-00-02-00-00-00      2             03-00-04-00-00-00      3             03-00-08-00-00-00      4             03-00-10-00-00-00      5             03-00-20-00-00-00      6             03-00-40-00-00-00      7             03-00-80-00-00-00      8             03-00-00-01-00-00      9             03-00-00-02-00-00     10             03-00-00-04-00-00     11             03-00-00-08-00-00   Or more succinctly, octets 3 and 4 of the functional address are   equal to (0x4000 >> (VRID - 1)) in non-canonical format.   Since a functional address cannot be used used as a MAC level source   address, the real MAC address is used as the MAC source address in   VRRP advertisements. This is not a problem for bridges since packets   addressed to functional addresses will be sent on the spanning-tree   explorer path [802.1D].   The functional address mode of operation MUST be implemented by   routers supporting VRRP on token ring.   Additionally, routers MAY support unicast mode of operation to take   advantage of newer token ring adapter implementations which support   non-promiscuous reception for multiple unicast MAC addresses and to   avoid both the multicast traffic and usage conflicts associated with   the use of token ring functional addresses. Unicast mode uses the   same mapping of VRIDs to virtual MAC addresses as Ethernet.  However,   one important difference exists. ARP request/reply packets contain   the virtual MAC address as the source MAC address. The reason for   this is that some token ring driver implementations keep a cache of   MAC address/source routing information independent of the ARP cache.Knight, et. al.             Standards Track                    [Page 22]RFC 2338                          VRRP                        April 1998   Hence, these implementations need have to receive a packet with the   virtual MAC address as the source address in order to transmit to   that MAC address in a source-route bridged network.   Unicast mode on token ring has one limitation which should be   considered.  If there are VRID routers on different source-route   bridge segments and there are host implementations which keep their   source-route information in the ARP cache and do not listen to   gratuitous ARPs, these hosts will not update their ARP source-route   information correctly when a switch-over occurs. The only possible   solution is to put all routers with the same VRID on the same source-   bridge segment and use techniques to prevent that bridge segment from   being a single point of failure. These techniques are beyond the   scope this document.   For both the multicast and unicast mode of operation, VRRP   advertisements sent to 224.0.0.18 should be encapsulated as described   in [RFC1469].10. Security Considerations   VRRP is designed for a range of internetworking environments that may   employ different security policies.  The protocol includes several   authentication methods ranging from no authentication, simple clear   text passwords, and strong authentication using IP Authentication   with MD5 HMAC.  The details on each approach including possible   attacks and recommended environments follows.   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.10.1 No Authentication   The use of this authentication type means that VRRP protocol   exchanges are not authenticated.  This type of authentication SHOULD   only be used in environments were there is minimal security risk and   little chance for configuration errors (e.g., two VRRP routers on a   LAN).10.2 Simple Text Password   The use of this authentication type means that VRRP protocol   exchanges are authenticated by a simple clear text password.Knight, et. al.             Standards Track                    [Page 23]RFC 2338                          VRRP                        April 1998   This type of authentication is useful to protect against accidental   misconfiguration of routers on a LAN.  It protects against routers   inadvertently backing up another router.  A new router must first be   configured with the correct password before it can run VRRP with   another router.  This type of authentication does not protect against   hostile attacks where the password can be learned by a node snooping   VRRP packets on the LAN.  The Simple Text Authentication combined   with the TTL check makes it difficult for a VRRP packet to be sent   from another LAN to disrupt VRRP operation.   This type of authentication is RECOMMENDED when there is minimal risk   of nodes on a LAN actively disrupting VRRP operation.  If this type   of authentication is used the user should be aware that this clear   text password is sent frequently, and therefore should not be the   same as any security significant password.10.3 IP Authentication Header   The use of this authentication type means the VRRP protocol exchanges   are authenticated using the mechanisms defined by the IP   Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP   and AH", [HMAC].  This provides strong protection against   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) which are independent from VRRP and   are not protected.11. Acknowledgments   The authors would like to thank Glen Zorn, and Michael Lane, Clark   Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve   Bellovin, and Thomas Narten for their comments and suggestions.12.  References   [802.1D]  International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std             802.1D, 1993 edition.   [AUTH]    Kent, S., and R. Atkinson, "IP Authentication Header",             Work in Progress.   [DISC]    Deering, S., "ICMP Router Discovery Messages", RFC 1256,             September 1991.Knight, et. al.             Standards Track                    [Page 24]RFC 2338                          VRRP                        April 1998   [DHCP]    Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,             March 1997.   [HMAC]    Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within             ESP and AH", Work in Progress.   [HSRP]    Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby             Router Protocol (HSRP)", RFC 2281, 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", STD 54, RFC 2328, April 1998.   [RIP]     Hedrick, C., "Routing Information Protocol", RFC 1058,             June 1988.   [RFC1469] Pusateri, T., "IP over Token Ring LANs", RFC 1469, June             1993.   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate             Requirement Levels", BCP 14, RFC 2119, March 1997.   [TKARCH]  IBM Token-Ring Network, Architecture Reference, Publication             SC30-3374-02, Third Edition, (September, 1989).13. Authors' 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   USAKnight, et. al.             Standards Track                    [Page 25]RFC 2338                          VRRP                        April 1998   David Whipple                        Phone: +1 206 703-3876   Microsoft Corporation                EMail: dwhipple@microsoft.com   One Microsoft Way   Redmond, WA USA 98052-6399   USA   Robert Hinden                        Phone: +1 408 990-2004   Nokia                                EMail: hinden@iprg.nokia.com   232 Java Drive   Sunnyvale, CA 94089   USA   Danny Mitzel                         Phone: +1 408 990-2037   Nokia                                EMail: mitzel@iprg.nokia.com   232 Java Drive   Sunnyvale, CA 94089   USA   Peter Hunt                           Phone: +1 408 990-2093   Nokia                                EMail: hunt@iprg.nokia.com   232 Java Drive   Sunnyvale, CA 94089   USA   P. Higginson                         Phone: +44 118 920 6293   Digital Equipment Corp.              EMail: higginson@mail.dec.com   Digital Park   Imperial Way   Reading   Berkshire   RG2 0TE   UK   M. Shand                             Phone: +44 118 920 4424   Digital Equipment Corp.              EMail: shand@mail.dec.com   Digital Park   Imperial Way   Reading   Berkshire   RG2 0TE   UK   Acee Lindem                          Phone: 1-919-254-1805   IBM Corporation                      E-Mail: acee@raleigh.ibm.com   P.O. Box 12195   Research Triangle Park, NC  27709   USAKnight, et. al.             Standards Track                    [Page 26]RFC 2338                          VRRP                        April 199814.  Full Copyright Statement   Copyright (C) The Internet Society (1998).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Knight, et. al.             Standards Track                    [Page 27]