doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc3768.txt b/doc/rfc/rfc3768.txt
new file mode 100644
index 0000000..07a272e
--- /dev/null
+++ b/doc/rfc/rfc3768.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                     R. Hinden, Ed.
+Request for Comments: 3768                                         Nokia
+Obsoletes: 2338                                               April 2004
+Category: Standards Track
+
+
+               Virtual Router Redundancy Protocol (VRRP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+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
+   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
+   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.
+
+Table of Contents
+
+   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
+       1.1.  Contributors. . . . . . . . . . . . . . . . . . . . . .   3
+       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . .   4
+       1.3.  Definitions . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Required Features . . . . . . . . . . . . . . . . . . . . . .   5
+       2.1.  IP Address Backup . . . . . . . . . . . . . . . . . . .   5
+       2.2.  Preferred Path Indication . . . . . . . . . . . . . . .   5
+       2.3.  Minimization of Unnecessary Service Disruptions . . . .   5
+       2.4.  Efficient Operation over Extended LANs. . . . . . . . .   6
+   3.  VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . .   6
+   4.  Sample Configurations . . . . . . . . . . . . . . . . . . . .   7
+
+
+
+Hinden                      Standards Track                     [Page 1]
+
+RFC 3768                          VRRP                        April 2004
+
+
+       4.1.  Sample Configuration 1. . . . . . . . . . . . . . . . .   7
+       4.2.  Sample Configuration 2. . . . . . . . . . . . . . . . .   9
+   5.  Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+       5.1.  VRRP Packet Format. . . . . . . . . . . . . . . . . . .  10
+       5.2.  IP Field Descriptions . . . . . . . . . . . . . . . . .  10
+       5.3.  VRRP Field Descriptions . . . . . . . . . . . . . . . .  11
+   6.  Protocol State Machine. . . . . . . . . . . . . . . . . . . .  13
+       6.1.  Parameters per Virtual Router . . . . . . . . . . . . .  13
+       6.2.  Timers. . . . . . . . . . . . . . . . . . . . . . . . .  14
+       6.3.  State Transition Diagram. . . . . . . . . . . . . . . .  15
+       6.4.  State Descriptions. . . . . . . . . . . . . . . . . . .  15
+   7.  Sending and Receiving VRRP Packets. . . . . . . . . . . . . .  18
+       7.1.  Receiving VRRP Packets. . . . . . . . . . . . . . . . .  18
+       7.2.  Transmitting Packets. . . . . . . . . . . . . . . . . .  19
+       7.3.  Virtual MAC Address . . . . . . . . . . . . . . . . . .  19
+   8.  Operational Issues. . . . . . . . . . . . . . . . . . . . . .  20
+       8.1.  ICMP Redirects. . . . . . . . . . . . . . . . . . . . .  20
+       8.2.  Host ARP Requests . . . . . . . . . . . . . . . . . . .  20
+       8.3.  Proxy ARP . . . . . . . . . . . . . . . . . . . . . . .  20
+       8.4.  Potential Forwarding Loop . . . . . . . . . . . . . . .  21
+   9.  Operation over FDDI, Token Ring, and ATM LANE . . . . . . . .  21
+       9.1.  Operation over FDDI . . . . . . . . . . . . . . . . . .  21
+       9.2.  Operation over Token Ring . . . . . . . . . . . . . . .  21
+       9.3.  Operation over ATM LANE . . . . . . . . . . . . . . . .  23
+   10. Security Considerations . . . . . . . . . . . . . . . . . . .  23
+   11. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  24
+   12. References. . . . . . . . . . . . . . . . . . . . . . . . . .  24
+       12.1. Normative References. . . . . . . . . . . . . . . . . .  24
+       12.2. Informative References. . . . . . . . . . . . . . . . .  25
+   13. Changes from RFC2338. . . . . . . . . . . . . . . . . . . . .  25
+   14. Editor's Address. . . . . . . . . . . . . . . . . . . . . . .  26
+   15. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  27
+
+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.
+
+   Running a dynamic routing protocol on every end-host may be
+   infeasible for a number of reasons, including administrative
+   overhead, processing overhead, security issues, or lack of a protocol
+   implementation for some platforms.  Neighbor or router discovery
+   protocols may require active participation by all hosts on a network,
+   leading to large timer values to reduce protocol overhead in the face
+
+
+
+Hinden                      Standards Track                     [Page 2]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   of large numbers of hosts.  This can result in a significant delay in
+   the detection of a lost (i.e., dead) neighbor, that may introduce
+   unacceptably long "black hole" periods.
+
+   The use of a statically configured default route is quite popular; it
+   minimizes configuration and processing overhead on the end-host and
+   is supported by virtually every IP implementation.  This mode of
+   operation is likely to persist as dynamic host configuration
+   protocols [DHCP] are deployed, which typically provide configuration
+   for an end-host IP address and default gateway.  However, this
+   creates a single point of failure.  Loss of the default router
+   results in a catastrophic event, isolating all end-hosts that are
+   unable to detect any alternate path that may be available.
+
+   The Virtual Router Redundancy Protocol (VRRP) is designed to
+   eliminate the single point of failure inherent in the static default
+   routed environment.  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 unavailable.  Any of the virtual router's IP
+   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
+   availability default path without requiring configuration of dynamic
+   routing or router discovery protocols on every end-host.
+
+   VRRP provides a function similar to the proprietary protocols "Hot
+   Standby Router Protocol (HSRP)" [HSRP] and "IP Standby Protocol"
+   [IPSTB].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+1.1.  Contributors
+
+   The following people, who are the authors of the RFC 2338 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 current RFC-Editor policies.
+
+
+
+
+
+
+
+
+Hinden                      Standards Track                     [Page 3]
+
+RFC 3768                          VRRP                        April 2004
+
+
+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.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
+                          more virtual routers.
+
+   IP Address Owner       The VRRP router that has the virtual router's
+                          IP address(es) as real interface address(es).
+                          This is the router that, when up, will respond
+                          to packets addressed to one of these IP
+                          addresses for ICMP pings, TCP connections,
+                          etc.
+
+   Primary IP Address     An IP address selected from the set of real
+                          interface addresses.  One possible selection
+                          algorithm is to always select the first
+                          address.  VRRP advertisements are always sent
+                          using the primary IP address as the source of
+                          the IP packet.
+
+   Virtual Router Master  The VRRP router that is assuming the
+                          responsibility of forwarding packets sent to
+                          the IP address(es) associated with the virtual
+                          router, and answering ARP requests for these
+                          IP addresses.  Note that if the IP address
+                          owner is available, then it will always become
+                          the Master.
+
+
+
+Hinden                      Standards Track                     [Page 4]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   Virtual Router Backup  The set of VRRP routers available to assume
+                          forwarding responsibility for a virtual router
+                          should the current Master fail.
+
+2.  Required Features
+
+   This section outlines the set of features that were considered
+   mandatory and that guided the design of VRRP.
+
+2.1.  IP Address Backup
+
+   Backup of IP addresses is the primary function of the Virtual Router
+   Redundancy Protocol.  While providing election of a Virtual Router
+   Master and the additional functionality described below, the protocol
+   should strive to:
+
+   -  Minimize the duration of black holes.
+   -  Minimize the steady state bandwidth overhead and processing
+      complexity.
+   -  Function over a wide variety of multiaccess LAN technologies
+      capable of supporting IP traffic.
+   -  Provide for election of multiple virtual routers on a network for
+      load balancing.
+   -  Support of multiple logical IP subnets on a single LAN segment.
+
+2.2.  Preferred Path Indication
+
+   A simple model of Master election among a set of redundant routers is
+   to treat each router with equal preference and claim victory after
+   converging to any router as Master.  However, there are likely to be
+   many environments where there is a distinct preference (or range of
+   preferences) among the set of redundant routers.  For example, this
+   preference may be based upon access link cost or speed, router
+   performance or reliability, or other policy considerations.  The
+   protocol should allow the expression of this relative path preference
+   in an intuitive manner, and guarantee Master convergence to the most
+   preferential router currently available.
+
+2.3.  Minimization of Unnecessary Service Disruptions
+
+   Once Master election has been performed then any unnecessary
+   transitions between Master and Backup routers can result in a
+   disruption in service.  The protocol should ensure after Master
+   election that no state transition is triggered by any Backup router
+   of equal or lower preference as long as the Master continues to
+   function properly.
+
+
+
+
+
+Hinden                      Standards Track                     [Page 5]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   Some environments may find it beneficial to avoid the state
+   transition triggered when a router becomes available that is
+   preferred over the current Master.  It may be useful to support an
+   override of the immediate convergence to the preferred path.
+
+2.4.  Efficient Operation over Extended LANs
+
+   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
+   in an extended LAN employing learning bridges can have a significant
+   effect on the bandwidth overhead of packets sent to the virtual
+   router.  If the virtual router MAC address is never used as the
+   source address in a link level frame then the station location is
+   never learned, resulting in flooding of all packets sent to the
+   virtual router.  To improve the efficiency in this environment the
+   protocol should: 1) use the virtual router MAC as the source in a
+   packet sent by the Master to trigger station learning; 2) trigger a
+   message immediately after transitioning to Master to update the
+   station learning; and 3) trigger periodic messages from the Master to
+   maintain the station learning cache.
+
+3.  VRRP Overview
+
+   VRRP specifies an election protocol to provide the virtual router
+   function described earlier.  All protocol messaging is performed
+   using IP multicast datagrams, thus the protocol can operate over a
+   variety of multiaccess LAN technologies supporting IP multicast.
+   Each VRRP virtual router has a single well-known MAC address
+   allocated to it.  This document currently only details the mapping to
+   networks using the IEEE 802 48-bit MAC address.  The virtual router
+   MAC address is used as the source in all periodic VRRP messages sent
+   by the Master router to enable bridge learning in an extended LAN.
+
+   A virtual router is defined by its virtual router identifier (VRID)
+   and a set of IP addresses.  A VRRP router may associate a virtual
+   router with its real addresses on an interface, and may also be
+   configured with additional virtual router mappings and priority for
+   virtual routers it is willing to backup.  The mapping between VRID
+   and addresses must be coordinated among all VRRP routers on a LAN.
+   However, there is no restriction against reusing a VRID with a
+   different address mapping on different LANs.  The scope of each
+   virtual router is restricted to a single LAN.
+
+   To minimize network traffic, only the Master for each virtual router
+   sends periodic VRRP Advertisement messages.  A Backup router will not
+   attempt to preempt the Master unless it has higher priority.  This
+   eliminates service disruption unless a more preferred path becomes
+   available.  It's also possible to administratively prohibit all
+
+
+
+Hinden                      Standards Track                     [Page 6]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   preemption attempts.  The only exception is that a VRRP router will
+   always become Master of any virtual router associated with addresses
+   it owns.  If the Master becomes unavailable then the highest priority
+   Backup will transition to Master after a short delay, providing a
+   controlled transition of the virtual router responsibility with
+   minimal service interruption.
+
+   The VRRP protocol design provides rapid transition from Backup to
+   Master to minimize service interruption, and incorporates
+   optimizations that reduce protocol complexity while guaranteeing
+   controlled Master transition for typical operational scenarios.  The
+   optimizations result in an election protocol with minimal runtime
+   state requirements, minimal active protocol states, and a single
+   message type and sender.  The typical operational scenarios are
+   defined to be two redundant routers and/or distinct path preferences
+   among each router.  A side effect when these assumptions are violated
+   (i.e., more than two redundant paths all with equal preference) is
+   that duplicate packets may be forwarded for a brief period during
+   Master election.  However, the typical scenario assumptions are
+   likely to cover the vast majority of deployments, loss of the Master
+   router is infrequent, and the expected duration in Master election
+   convergence is quite small ( << 1 second ).  Thus the VRRP
+   optimizations represent significant simplifications in the protocol
+   design while incurring an insignificant probability of brief network
+   degradation.
+
+4.  Sample Configurations
+
+4.1.  Sample Configuration 1
+
+   The following figure shows a simple network with two VRRP routers
+   implementing one virtual router.  Note that this example is provided
+   to help understand the protocol, but is not expected to occur in
+   actual practice.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden                      Standards Track                     [Page 7]
+
+RFC 3768                          VRRP                        April 2004
+
+
+            +-----------+      +-----------+
+            |   Rtr1    |      |   Rtr2    |
+            |(MR VRID=1)|      |(BR VRID=1)|
+            |           |      |           |
+    VRID=1  +-----------+      +-----------+
+    IP A ---------->*            *<--------- IP B
+                    |            |
+                    |            |
+  ------------------+------------+-----+--------+--------+--------+--
+                                       ^        ^        ^        ^
+                                       |        |        |        |
+                                     (IP A)   (IP A)   (IP A)   (IP A)
+                                       |        |        |        |
+                                    +--+--+  +--+--+  +--+--+  +--+--+
+                                    |  H1 |  |  H2 |  |  H3 |  |  H4 |
+                                    +-----+  +-----+  +--+--+  +--+--+
+     Legend:
+              ---+---+---+--  =  Ethernet, Token Ring, or FDDI
+                           H  =  Host computer
+                          MR  =  Master Router
+                          BR  =  Backup Router
+                           *  =  IP Address
+                        (IP)  =  default router for hosts
+
+   Eliminating all mention of VRRP (VRID=1) from the figure above leaves
+   it as a typical IP deployment.  Each router is permanently assigned
+   an IP address on the LAN interface (Rtr1 is assigned IP A and Rtr2 is
+   assigned IP B), and each host installs a static default route through
+   one of the routers (in this example they all use Rtr1's IP A).
+
+   Moving to the VRRP environment, each router has the exact same
+   permanently assigned IP address.  Rtr1 is said to be the IP address
+   owner of IP A, and Rtr2 is the IP address owner of IP B.  A virtual
+   router is then defined by associating a unique identifier (the
+   virtual router ID) with the address owned by a router.  Finally, the
+   VRRP protocol manages virtual router fail over to a backup router.
+
+   The example above shows a virtual router configured to cover the IP
+   address owned by Rtr1 (VRID=1,IP_Address=A).  When VRRP is enabled on
+   Rtr1 for VRID=1 it will assert itself as Master, with priority=255,
+   since it is the IP address owner for the virtual router IP address.
+   When VRRP is enabled on Rtr2 for VRID=1 it will transition to Backup,
+   with priority=100, since it is not the IP address owner.  If Rtr1
+   should fail then the VRRP protocol will transition Rtr2 to Master,
+   temporarily taking over forwarding responsibility for IP A to provide
+   uninterrupted service to the hosts.
+
+
+
+
+
+Hinden                      Standards Track                     [Page 8]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   Note that in this example IP B is not backed up, it is only used by
+   Rtr2 as its interface address.  In order to backup IP B, a second
+   virtual router must be configured.  This is shown in the next
+   section.
+
+4.2.  Sample Configuration 2
+
+   The following figure shows a configuration with two virtual routers
+   with the hosts spitting their traffic between them.  This example is
+   expected to be very common in actual practice.
+
+            +-----------+      +-----------+
+            |   Rtr1    |      |   Rtr2    |
+            |(MR VRID=1)|      |(BR VRID=1)|
+            |(BR VRID=2)|      |(MR VRID=2)|
+    VRID=1  +-----------+      +-----------+  VRID=2
+    IP A ---------->*            *<---------- IP B
+                    |            |
+                    |            |
+  ------------------+------------+-----+--------+--------+--------+--
+                                       ^        ^        ^        ^
+                                       |        |        |        |
+                                     (IP A)   (IP A)   (IP B)   (IP B)
+                                       |        |        |        |
+                                    +--+--+  +--+--+  +--+--+  +--+--+
+                                    |  H1 |  |  H2 |  |  H3 |  |  H4 |
+                                    +-----+  +-----+  +--+--+  +--+--+
+     Legend:
+              ---+---+---+--  =  Ethernet, Token Ring, or FDDI
+                           H  =  Host computer
+                          MR  =  Master Router
+                          BR  =  Backup Router
+                           *  =  IP Address
+                        (IP)  =  default router for hosts
+
+   In the example above, half of the hosts have configured a static
+   route through Rtr1's IP A and half are using Rtr2's IP B.  The
+   configuration of virtual router VRID=1 is exactly the same as in the
+   first example (see section 4.1), and a second virtual router has been
+   added to cover the IP address owned by Rtr2 (VRID=2, IP_Address=B).
+   In this case Rtr2 will assert itself as Master for VRID=2 while Rtr1
+   will act as a backup.  This scenario demonstrates a deployment
+   providing load splitting when both routers are available while
+   providing full redundancy for robustness.
+
+
+
+
+
+
+
+Hinden                      Standards Track                     [Page 9]
+
+RFC 3768                          VRRP                        April 2004
+
+
+5.  Protocol
+
+   The purpose of the VRRP packet is to communicate to all VRRP routers
+   the priority and the state of the Master router associated with the
+   Virtual Router ID.
+
+   VRRP packets are sent encapsulated in IP packets.  They are sent to
+   the IPv4 multicast address assigned to VRRP.
+
+5.1.  VRRP Packet Format
+
+   This section defines the format of the VRRP packet and the relevant
+   fields in the IP header.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Version| Type  | Virtual Rtr ID|   Priority    | Count IP Addrs|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Auth Type   |   Adver Int   |          Checksum             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         IP Address (1)                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            .                                  |
+   |                            .                                  |
+   |                            .                                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         IP Address (n)                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Authentication Data (1)                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Authentication Data (2)                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.2.  IP Field Descriptions
+
+5.2.1.  Source Address
+
+   The primary IP address of the interface the packet is being sent
+   from.
+
+
+
+
+
+
+
+
+
+
+
+Hinden                      Standards Track                    [Page 10]
+
+RFC 3768                          VRRP                        April 2004
+
+
+5.2.2.  Destination Address
+
+   The IP multicast address as assigned by the IANA for VRRP is:
+
+      224.0.0.18
+
+   This is a link local scope multicast address.  Routers MUST NOT
+   forward a datagram with this destination address regardless of its
+   TTL.
+
+5.2.3.  TTL
+
+   The TTL MUST be set to 255.  A VRRP router receiving a packet with
+   the TTL not equal to 255 MUST discard the packet.
+
+5.2.4.  Protocol
+
+   The IP protocol number assigned by the IANA for VRRP is 112
+   (decimal).
+
+5.3.  VRRP Field Descriptions
+
+5.3.1.  Version
+
+   The version field specifies the VRRP protocol version of this packet.
+   This document defines version 2.
+
+5.3.2.  Type
+
+   The type field specifies the type of this VRRP packet.  The only
+   packet type defined in this version of the protocol is:
+
+      1      ADVERTISEMENT
+
+   A packet with unknown type MUST be discarded.
+
+5.3.3.  Virtual Rtr ID (VRID)
+
+   The Virtual Router Identifier (VRID) field identifies the virtual
+   router this packet is reporting status for.  Configurable item in the
+   range 1-255 (decimal).  There is no default.
+
+5.3.4.  Priority
+
+   The priority field specifies the sending VRRP router's priority for
+   the virtual router.  Higher values equal higher priority.  This field
+   is an 8 bit unsigned integer field.
+
+
+
+
+Hinden                      Standards Track                    [Page 11]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   The priority value for the VRRP router that owns the IP address(es)
+   associated with the virtual router MUST be 255 (decimal).
+
+   VRRP routers backing up a virtual router MUST use priority values
+   between 1-254 (decimal).  The default priority value for VRRP routers
+   backing up a virtual router is 100 (decimal).
+
+   The priority value zero (0) has special meaning indicating that the
+   current Master has stopped participating in VRRP.  This is used to
+   trigger Backup routers to quickly transition to Master without having
+   to wait for the current Master to timeout.
+
+5.3.5.  Count IP Addrs
+
+   The number of IP addresses contained in this VRRP advertisement.
+
+5.3.6.  Authentication Type
+
+   The authentication type field identifies the authentication method
+   being utilized.  Authentication type is unique on a Virtual Router
+   basis.  The authentication type field is an 8 bit unsigned integer.
+   A packet with unknown authentication type or that does not match the
+   locally configured authentication method MUST be discarded.
+
+   Note:  Earlier version of the VRRP specification had several defined
+   authentication types [RFC2338].  These were removed in this
+   specification because operational experience showed that they did not
+   provide any real security and would only cause multiple masters to be
+   created.
+
+   The authentication methods currently defined are:
+
+      0 - No Authentication
+      1 - Reserved
+      2 - Reserved
+
+5.3.6.1.  Authentication Type 0 - No Authentication
+
+   The use of this authentication type means that VRRP protocol
+   exchanges are not authenticated.  The contents of the Authentication
+   Data field should be set to zero on transmission and ignored on
+   reception.
+
+5.3.6.2.  Authentication Type 1 - Reserved
+
+   This authentication type is reserved to maintain backwards
+   compatibility with RFC 2338.
+
+
+
+
+Hinden                      Standards Track                    [Page 12]
+
+RFC 3768                          VRRP                        April 2004
+
+
+5.3.6.3.  Authentication Type 2 - Reserved
+
+   This authentication type is reserved to maintain backwards
+   compatibility with RFC 2338.
+
+5.3.7.  Advertisement Interval (Adver Int)
+
+   The Advertisement interval indicates the time interval (in seconds)
+   between ADVERTISEMENTS.  The default is 1 second.  This field is used
+   for troubleshooting misconfigured routers.
+
+5.3.8.  Checksum
+
+   The checksum field is used to detect data corruption in the VRRP
+   message.
+
+   The checksum is the 16-bit one's complement of the one's complement
+   sum of the entire VRRP message starting with the version field.  For
+   computing the checksum, the checksum field is set to zero.  See RFC
+   1071 for more detail [CKSM].
+
+5.3.9.  IP Address(es)
+
+   One or more IP addresses that are associated with the virtual router.
+   The number of addresses included is specified in the "Count IP Addrs"
+   field.  These fields are used for troubleshooting misconfigured
+   routers.
+
+5.3.10.  Authentication Data
+
+   The authentication string is currently only used to maintain
+   backwards compatibility with RFC 2338.  It SHOULD be set to zero on
+   transmission and ignored on reception.
+
+6.  Protocol State Machine
+
+6.1.  Parameters per Virtual Router
+
+   VRID                    Virtual Router Identifier.  Configurable item
+                           in the range 1-255 (decimal).  There is no
+                           default.
+
+   Priority                Priority value to be used by this VRRP router
+                           in Master election for this virtual router.
+                           The value of 255 (decimal) is reserved for
+                           the router that owns the IP addresses
+                           associated with the virtual router.  The
+                           value of 0 (zero) is reserved for Master
+
+
+
+Hinden                      Standards Track                    [Page 13]
+
+RFC 3768                          VRRP                        April 2004
+
+
+                           router to indicate it is releasing
+                           responsibility for the virtual router.  The
+                           range 1-254 (decimal) is available for VRRP
+                           routers backing up the virtual router.  The
+                           default value is 100 (decimal).
+
+   IP_Addresses            One or more IP addresses associated with this
+                           virtual router.  Configured item.  No
+                           default.
+
+   Advertisement_Interval  Time interval between ADVERTISEMENTS
+                           (seconds).  Default is 1 second.
+
+   Skew_Time               Time to skew Master_Down_Interval in seconds.
+                           Calculated as:
+
+                             ( (256 - Priority) / 256 )
+
+   Master_Down_Interval    Time interval for Backup to declare Master
+                           down (seconds).  Calculated as:
+
+                             (3 * Advertisement_Interval) + Skew_time
+
+   Preempt_Mode            Controls whether a higher priority Backup
+                           router preempts a lower priority Master.
+                           Values are True to allow preemption and False
+                           to prohibit preemption.  Default is True.
+
+                           Note: Exception is that the router that owns
+                           the IP address(es) associated with the
+                           virtual router always preempts independent of
+                           the setting of this flag.
+
+   Authentication_Type     Type of authentication being used.  Values
+                           are defined in section 5.3.6.
+
+   Authentication_Data     Authentication data specific to the
+                           Authentication_Type being used.
+
+6.2.  Timers
+
+   Master_Down_Timer       Timer that fires when ADVERTISEMENT has not
+                           been heard for Master_Down_Interval.
+
+   Adver_Timer             Timer that fires to trigger sending of
+                           ADVERTISEMENT based on
+                           Advertisement_Interval.
+
+
+
+
+Hinden                      Standards Track                    [Page 14]
+
+RFC 3768                          VRRP                        April 2004
+
+
+6.3.  State Transition Diagram
+
+                      +---------------+
+           +--------->|               |<-------------+
+           |          |  Initialize   |              |
+           |   +------|               |----------+   |
+           |   |      +---------------+          |   |
+           |   |                                 |   |
+           |   V                                 V   |
+   +---------------+                       +---------------+
+   |               |---------------------->|               |
+   |    Master     |                       |    Backup     |
+   |               |<----------------------|               |
+   +---------------+                       +---------------+
+
+6.4.  State Descriptions
+
+   In the state descriptions below, the state names are identified by
+   {state-name}, and the packets are identified by all upper case
+   characters.
+
+   A VRRP router implements an instance of the state machine for each
+   virtual router election it is participating in.
+
+6.4.1.  Initialize
+
+   The purpose of this state is to wait for a Startup event.  If a
+   Startup event is received, then:
+
+   -  If the Priority = 255 (i.e., the router owns the IP address(es)
+      associated with the virtual router)
+
+      o  Send an ADVERTISEMENT
+      o  Broadcast a gratuitous ARP request containing the virtual
+         router MAC address for each IP address associated with the
+         virtual router.
+      o  Set the Adver_Timer to Advertisement_Interval
+      o  Transition to the {Master} state
+
+      else
+
+      o  Set the Master_Down_Timer to Master_Down_Interval
+      o  Transition to the {Backup} state
+
+      endif
+
+
+
+
+
+
+Hinden                      Standards Track                    [Page 15]
+
+RFC 3768                          VRRP                        April 2004
+
+
+6.4.2.  Backup
+
+   The purpose of the {Backup} state is to monitor the availability and
+   state of the Master Router.
+
+   While in this state, a VRRP router MUST do the following:
+
+   -  MUST NOT respond to ARP requests for the IP address(s) associated
+      with the virtual router.
+
+   -  MUST discard packets with a destination link layer MAC address
+      equal to the virtual router MAC address.
+
+   -  MUST NOT accept packets addressed to the IP address(es) associated
+      with the virtual router.
+
+   -  If a Shutdown event is received, then:
+
+      o  Cancel the Master_Down_Timer
+      o  Transition to the {Initialize} state
+
+         endif
+
+   -  If the Master_Down_Timer fires, then:
+
+      o  Send an ADVERTISEMENT
+      o  Broadcast a gratuitous ARP request containing the virtual
+         router MAC address for each IP address associated with the
+         virtual router
+      o  Set the Adver_Timer to Advertisement_Interval
+      o  Transition to the {Master} state
+
+         endif
+
+   -  If an ADVERTISEMENT is received, then:
+
+      If the Priority in the ADVERTISEMENT is Zero, then:
+
+      o  Set the Master_Down_Timer to Skew_Time
+
+         else:
+
+            If Preempt_Mode is False, or If the Priority in the
+            ADVERTISEMENT is greater than or equal to the local
+            Priority, then:
+
+             o Reset the Master_Down_Timer to Master_Down_Interval
+
+
+
+
+Hinden                      Standards Track                    [Page 16]
+
+RFC 3768                          VRRP                        April 2004
+
+
+            else:
+
+             o Discard the ADVERTISEMENT
+
+            endif
+         endif
+      endif
+
+6.4.3.  Master
+
+   While in the {Master} state the router functions as the forwarding
+   router for the IP address(es) associated with the virtual router.
+
+   While in this state, a VRRP router MUST do the following:
+
+   -  MUST respond to ARP requests for the IP address(es) associated
+      with the virtual router.
+
+   -  MUST forward packets with a destination link layer MAC address
+      equal to the virtual router MAC address.
+
+   -  MUST NOT accept packets addressed to the IP address(es) associated
+      with the virtual router if it is not the IP address owner.
+
+   -  MUST accept packets addressed to the IP address(es) associated
+      with the virtual router if it is the IP address owner.
+
+   -  If a Shutdown event is received, then:
+
+      o  Cancel the Adver_Timer
+      o  Send an ADVERTISEMENT with Priority = 0
+      o  Transition to the {Initialize} state
+
+         endif
+
+      -  If the Adver_Timer fires, then:
+
+      o  Send an ADVERTISEMENT o  Reset the Adver_Timer to
+         Advertisement_Interval
+
+         endif
+
+      -  If an ADVERTISEMENT is received, then:
+
+         If the Priority in the ADVERTISEMENT is Zero, then:
+
+      o  Send an ADVERTISEMENT
+      o  Reset the Adver_Timer to Advertisement_Interval
+
+
+
+Hinden                      Standards Track                    [Page 17]
+
+RFC 3768                          VRRP                        April 2004
+
+
+         else:
+
+            If the Priority in the ADVERTISEMENT is greater than the
+            local Priority,
+            or
+            If the Priority in the ADVERTISEMENT is equal to the local
+            Priority and the primary IP Address of the sender is greater
+            than the local primary IP Address, then:
+
+             o Cancel Adver_Timer
+             o Set Master_Down_Timer to Master_Down_Interval
+             o Transition to the {Backup} state
+
+            else:
+
+             o Discard ADVERTISEMENT
+
+            endif
+         endif
+      endif
+
+7.  Sending and Receiving VRRP Packets
+
+7.1.  Receiving VRRP Packets
+
+   Performed the following functions when a VRRP packet is received:
+
+   -  MUST verify that the IP TTL is 255.
+   -  MUST verify the VRRP version is 2.
+   -  MUST verify that the received packet contains the complete VRRP
+      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
+
+
+
+
+
+Hinden                      Standards Track                    [Page 18]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   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 checksum
+   -  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.
+
+
+
+
+
+
+
+
+
+Hinden                      Standards Track                    [Page 19]
+
+RFC 3768                          VRRP                        April 2004
+
+
+8.  Operational Issues
+
+8.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 ARP
+   message.  Doing otherwise could cause hosts to learn the real MAC
+   address of the VRRP router.
+
+
+
+Hinden                      Standards Track                    [Page 20]
+
+RFC 3768                          VRRP                        April 2004
+
+
+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 LANE
+
+9.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 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.
+
+
+
+Hinden                      Standards Track                    [Page 21]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   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
+   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.
+
+   Since a functional address cannot be 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].
+
+
+
+
+
+Hinden                      Standards Track                    [Page 22]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   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 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.
+
+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.  Due to the nature of the VRRP protocol, even if
+   VRRP messages are cryptographically protected, it does not prevent
+   hostile routers from behaving as if they are a VRRP master, creating
+   multiple masters.  Authentication of VRRP messages could have
+
+
+
+Hinden                      Standards Track                    [Page 23]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   prevented a hostile router from causing all properly functioning
+   routers from going into backup state.  However, having multiple
+   masters can cause as much disruption as no routers, which
+   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
+   (setting TTL=255, checking on receipt) that protects against VRRP
+   packets being injected from another remote network.  This limits most
+   vulnerabilities to local attacks.
+
+   VRRP does not provide any confidentiality.  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.
+
+11.  Acknowledgements
+
+   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, Rob Coltun, Radia Perlman,
+   Russ Housley, Harald Alvestrand, Steve Bellovin, Ned Freed, Ted
+   Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex Zinin for
+   their comments and suggestions.
+
+12.  References
+
+12.1.  Normative References
+
+   [802.1D]  International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std
+             802.1D, 1993 edition.
+
+   [CKSM]    Braden, R., Borman, D. and C. Partridge, "Computing the
+             Internet checksum", RFC 1071, September 1988.
+
+
+
+
+Hinden                      Standards Track                    [Page 24]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   [HSRP]    Li, T., Cole, B., Morton, P. and D. Li, "Cisco Hot Standby
+             Router Protocol (HSRP)", RFC 2281, March 1998.
+
+   [IPSTB]   Higginson, P. and 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.
+
+   [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area
+             Networks", RFC 1469, June 1993.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel,
+             D., Hunt, P., Higginson, P., Shand, M. and A. Lindem,
+             "Virtual Router Redundancy Protocol", RFC 2338, April 1998.
+
+   [TKARCH]  IBM Token-Ring Network, Architecture Reference, Publication
+             SC30-3374-02, Third Edition, (September, 1989).
+
+12.2.  Informative References
+
+   [DISC]    Deering, S., Ed., "ICMP Router Discovery Messages", RFC
+             1256, September 1991.
+
+   [DHCP]    Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+             March 1997.
+
+   [OSPF]    Moy, J., "OSPF version 2", STD 54, RFC 2328, April 1998.
+
+   [RIP]     Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
+             1998.
+
+13.  Changes from RFC 2338
+
+   -  Moved authors of RFC 2338 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 RFC 2338.
+      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 and describe vulnerabilities.
+
+
+
+Hinden                      Standards Track                    [Page 25]
+
+RFC 3768                          VRRP                        April 2004
+
+
+   -  Revised the section 4 examples text with a clearer description of
+      mapping of IP address owner, priorities, etc.
+   -  Clarify the section 7.1 text describing address list validation.
+   -  Corrected text in Preempt_Mode definition.
+   -  Changed authentication to be per Virtual Router instead of per
+      Interface.
+   -  Added new subsection (9.3) stating that VRRP over ATM LANE is
+      beyond the scope of this document.
+   -  Clarified text describing received packet length check.
+   -  Clarified text describing received authentication check.
+   -  Clarified text describing VRID verification check.
+   -  Added new subsection (8.4) describing need to not forward packets
+      for adopted IP addresses.
+   -  Added clarification to the security considerations section.
+   -  Added reference for computing the internet checksum.
+   -  Updated references and author information.
+   -  Various small editorial changes.
+
+14.  Editor's Address
+
+   Robert Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA 94043
+   US
+
+   Phone: +1 650 625-2004
+   EMail: bob.hinden@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden                      Standards Track                    [Page 26]
+
+RFC 3768                          VRRP                        April 2004
+
+
+15.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Hinden                      Standards Track                    [Page 27]
+