packet (including fixed fields, IP Address(es), and        Authentication Data).      - MUST verify the VRRP checksum      - MUST verify that the VRID is configured on the receiving        interface and the local router is not the IP Address owner        (Priority equals 255 (decimal)).      - MUST verify that the Auth Type matches the locally configured        authentication method for the virtual router and perform that        authentication method   If any one of the above checks fails, the receiver MUST discard the   packet, SHOULD log the event and MAY indicate via network management   that an error occurred.      - MAY verify that "Count IP Addrs" and the list of IP Address        matches the IP_Addresses configured for the VRID   If the above check fails, the receiver SHOULD log the event and MAY   indicate via network management that a misconfiguration was detected.   If the packet was not generated by the address owner (Priority does   not equal 255 (decimal)), the receiver MUST drop the packet,   otherwise continue processing.      - MUST verify that the Adver Interval in the packet is the same as        the locally configured for this virtual router   If the above check fails, the receiver MUST discard the packet,   SHOULD log the event and MAY indicate via network management that a   misconfiguration was detected.7.2 Transmitting VRRP Packets   The following operations MUST be performed when transmitting a VRRP   packet.      - Fill in the VRRP packet fields with the appropriate virtual        router configuration state      - Compute the VRRP checksumdraft-ietf-vrrp-spec-v2-05.txt                                 [Page 20]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000      - Set the source MAC address to Virtual Router MAC Address      - Set the source IP address to interface primary IP address      - Set the IP protocol to VRRP      - Send the VRRP packet to the VRRP IP multicast group   Note: VRRP packets are transmitted with the virtual router MAC   address as the source MAC address to ensure that learning bridges   correctly determine the LAN segment the virtual router is attached   to.7.3 Virtual Router MAC Address   The virtual router MAC address associated with a virtual router is an   IEEE 802 MAC Address in the following format:      00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)   The first three octets are derived from the IANA's OUI.  The next two   octets (00-01) indicate the address block assigned to the VRRP   protocol.  {VRID} is the VRRP Virtual Router Identifier.  This   mapping provides for up to 255 VRRP routers on a network.draft-ietf-vrrp-spec-v2-05.txt                                 [Page 21]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 20008.  Operational Issues8.1 ICMP Redirects   ICMP Redirects may be used normally when VRRP is running between a   group of routers.  This allows VRRP to be used in environments where   the topology is not symmetric.   The IP source address of an ICMP redirect should be the address the   end host used when making its next hop routing decision.  If a VRRP   router is acting as Master for virtual router(s) containing addresses   it does not own, then it must determine which virtual router the   packet was sent to when selecting the redirect source address.  One   method to deduce the virtual router used is to examine the   destination MAC address in the packet that triggered the redirect.   It may be useful to disable Redirects for specific cases where VRRP   is being used to load share traffic between a number of routers in a   symmetric topology.8.2  Host ARP Requests   When a host sends an ARP request for one of the virtual router IP   addresses, the Master virtual router MUST respond to the ARP request   with the virtual MAC address for the virtual router.  The Master   virtual router MUST NOT respond with its physical MAC address.  This   allows the client to always use the same MAC address regardless of   the current Master router.   When a VRRP router restarts or boots, it SHOULD not send any ARP   messages with its physical MAC address for the IP address it owns, it   should only send ARP messages that include Virtual MAC addresses.   This may entail:    - When configuring an interface, VRRP routers should broadcast a      gratuitous ARP request containing the virtual router MAC address      for each IP address on that interface.    - At system boot, when initializing interfaces for VRRP operation;      delay gratuitous ARP requests and ARP responses until both the IP      address and the virtual router MAC address are configured.8.3 Proxy ARP   If Proxy ARP is to be used on a VRRP router, then the VRRP router   must advertise the Virtual Router MAC address in the Proxy ARPdraft-ietf-vrrp-spec-v2-05.txt                                 [Page 22]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000   message.  Doing otherwise could cause hosts to learn the real MAC   address of the VRRP router.8.4 Potential Forwarding Loop   A VRRP router SHOULD not forward packets addressed to the IP   Address(es) it becomes Master for if it is not the owner.  Forwarding   these packets would result in unnecessary traffic.  Also in the case   of LANs that receive packets they transmit (e.g., token ring) this   can result in a forwarding loop that is only terminated when the IP   TTL expires.   One such mechanism for VRRP routers is to add/delete a reject host   route for each adopted IP address when transitioning to/from MASTER   state.9.  Operation over FDDI, Token Ring, and ATM LANE9.1 Operation over FDDI   FDDI interfaces remove from the FDDI ring frames that have a source   MAC address matching the device's hardware address.  Under some   conditions, such as router isolations, ring failures, protocol   transitions, etc., VRRP may cause there to be more than one Master   router.  If a Master router installs the virtual router MAC address   as the hardware address on a FDDI device, then other Masters'   ADVERTISEMENTS will be removed from the ring during the Master   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 that 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 tokendraft-ietf-vrrp-spec-v2-05.txt                                 [Page 23]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000      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 uses   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.draft-ietf-vrrp-spec-v2-05.txt                                 [Page 24]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000   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 that 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.   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 that should be   considered.  If there are VRID routers on different source-route   bridge segments and there are host implementations that 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].9.3  Operation over ATM LANE   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   document.draft-ietf-vrrp-spec-v2-05.txt                                 [Page 25]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 200010. 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.   The security measures discussed in the following sections only   provide various kinds of authentication.  No confidentiality is   provided.  Confidentiality is not necessary for the correct operation   of VRRP and there is no information in the VRRP messages that must be   kept secret from other nodes on the LAN.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