2.5.9 Virtual Router Redundancy Protocol (vrrp)

Last Modified: 2003-08-25

Chair(s):
Radia Perlman <radia.perlman@sun.com>
Mukesh Gupta <Mukesh.Gupta@nokia.com>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: vrrp@ietf.org
To Subscribe: vrrp-request@ietf.org
In Body: subscribe vrrp
Archive: https://www1.ietf.org/mail-archive/working-groups/vrrp/current/index.html
Description of Working Group:
The purpose of this working group is to define and develop a standard
virtual router redundancy protocol for IPv4 and IPv6.  A virtual
router redundancy protocol is a protocol which allows several
routers on a multiaccess link to utilize the same virtual IP address.
One router will be elected as a master with the other routers acting as
backups in case of the failure of the master router.  The primary
motivation to using a virtual router redundancy protocol is that host
systems may be configured (manually or via DHCP) with a single default
gateway, rather than running an active routing protocol.  The protocol
should also support the ability to load share traffic when both routers
are up.

The goals of this working group are:

1. Define and develop a standard virtual router redundancy protocol
    for IPv4 and IPv6.

2. Develop VRRP MIB(s).

3. Separate specifications will be developed for IPv4 and IPv6.

4. Determine whether static (configuration based) load sharing is
    adequate or if some amount of dynamic load sharing is required.

5. Working group will examine security issues to determine what
    security threats it is appropriate for the VRRP protocol to
    handle and include the appropriate mechanisms in the VRRP protocol.

  6. The internet draft "Virtual Router Redundancy Protocol"
    (draft-hinden-vrrp-00.txt) will be use as the basis of virtual
    router redundancy protocol.  The working group will also consider
    other Internet-Drafts related to this topic allowing for issues
    regarding change control, security, running code, etc.

  7. Intellectual property issues regarding the technology to
      develop a virtual router redundancy protocol will be identified
      and addressed.
Goals and Milestones:
Done  Charter Working Group
Done  Issue new Internet Drafts for IPv4 version of the protocol.
Done  Review and finalize IPv4 Internet Drafts.
Done  Issue Internet Draft for IPv6 version of VRRP.
Done  Submit revised IPv4 Internet Drafts to IESG for proposed standard.
Done  Issue VRRP MIB drafts.
Done  Issue revised draft for IPv6 version of VRRP.
Done  Finalize MIB draft and submit to IESG.
Done  Resolve open issues with authentication methods
Done  Issue VRRPv3 (VRRP for IPv6) MIB drafts
Aug 03  Submit updated version of VRRP (IPv4) for Draft Standard
Oct 03  Submit VRRP for IPv6 (VRRPv3) for Proposed Standard
Dec 03  Submit MIB for VRRPv3 for Proposed Standard
Dec 03  Review the WG goals and future potential
Internet-Drafts:
  • - draft-ietf-vrrp-spec-v2-09.txt
  • - draft-ietf-vrrp-ipv6-spec-05.txt
  • - draft-ietf-vrrp-ipv6-mib-00.txt
  • Request For Comments:
    Virtual Router Redundancy Protocol (RFC 2338) (59871 bytes)
    Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2 (RFC 2787) (56672 bytes)

    Current Meeting Report

    ===================VRRP 7/16/2003
    
    
    Milestone review
    
    
    New milestones were proposed.
    ===
    Mar 2003 - Resolve open issues with authentication methods [DONE MAR 2003]
    Aug 2003 - Submit updated version of VRRP (IPv4) for Draft Standard
    Oct 2003 - Submit VRRP for IPv6 (VRRPv3) for Proposed Standard
    Dec 2003 - Submit MIB for VRRPv3 for Proposed Standard
    Dec 2003 - Review the WG goals and future potential
    ===
    
    
    VRRPv3 MIB
    
    
    There was a discussion about whether there should just be a single 
    combined MIB for IPv4 and IPv6, or whether there should be two, and if 
    there were two, one should be IPv4-only, but should the other be 
    combined IPv4 and IPv6, or IPv6-only. The current draft is assuming 
    IPv4-only plus IPv6-only. The conclusion was that it might be good to try to 
    do a strawman IPv4+IPv6 and see if that works well. One argument for why 
    there couldn't be a single MIB was that VRRPv2 is stable while VRRPv3 is 
    still evolving, and there ought to be a stable MIB to go along with the 
    stable protocol. Another is that VRRPv2 and VRRPv3 might be 
    sufficiently different protocols that it would be confusing to try to 
    combine them.
    
    
    VRRPv2 spec update
    
    
    Bob Hinden presented the changes to VRRPv2, which were mostly 
    editorial other than removing the authentication methods, and adding to the 
    security considerations section an explanation for having done so. An 
    issue was raised about having too many listed authors, and some 
    obsolete addresses for them. The conclusion was that Bob Hinden should be 
    listed as "editor", and a "contributors" section should be added 
    acknowledging the others. There was an issue that had been raised on the 
    mailing list about possible pathological behavior when multiple backup 
    routers had equal priorities, and on the mailing list a suggestion had been 
    made for adding a tie-breaker based on IP address. After discussion 
    during the meeting, it was concluded that the particular section of code 
    involving backup router ties would not be invoked, because a router, once it 
    sends a VRRP message, has already decided it is master, and the master 
    portion has the IP-address tie-breaker. So the conclusion was that the 
    election logic was fine as is. The sense of the room was that VRRPv2 is 
    ready for wg last call.
    
    
    Sub-second Timers
    
    
    Karen O'Donoghue gave a presentation explaining the need for faster 
    convergence (less than one second) than could be done using timers in 
    units of seconds. The sense of the room was that they were convinced of the 
    need, at least for IPv6. It would be difficult to do it for IPv4 because it 
    would be an incompatible change, and it would be undesirable to delay the 
    specification. Various encoding techniques were described, the most 
    straightforward being making the size of the timer field longer and the 
    units smaller (perhaps 100 ms), and other suggestions involving 
    exponential encoding so as to fit into the same sized field. The 
    conclusion was to pursue this on the mailing list for v6, and if it is 
    desired for IPv4, to have a new draft for a new version of VRRP for IPv4 
    (perhaps version number 4). A quick check was made to ensure that VRRPv2 
    does indeed say that a VRRPv2 router should drop VRRP messages with 
    unknown version numbers, which is required in order to safely roll out a new 
    version of VRRP.
     
    VRRPv3
    
    
    As with v2, removed authentication types and added explanation in 
    security considerations section.
    
    
    An issue from the mailing list was discussed, which is that using VMACs 
    causes layer 2 addresses to change locations, which is somewhat 
    dangerous in a bridged LAN. For IPv4, VMACs are necessary because there are 
    implementations of hosts (e.g., Win 95) that do not update their ARP 
    caches when they receive gratuitous ARP messages. But the question was 
    raised as to whether VMACs, and perhaps even VRRP, could be avoided for 
    IPv6.
    
    
    The conclusion about whether VRRP for IPv6 could be avoided was that it 
    could not. VRRP for IPv6 could not be avoided because the neighbor 
    discovery mechanism in IPv6 would not be able to react to changes as 
    quickly as a mechanism such as VRRP, confined to a community of a few 
    routers. And even if IPv6 neighbor discovery could in theory be 
    modified to be as responsive as VRRP, the VRRP WG could not impose 
    changes to a different WG.
    
    
    The second issue was whether VMACs could be avoided for IPv6, i.e., have 
    VRRPv3 still elect one router to represent the IP address, but not move MAC 
    addresses. The elected router would use its own MAC address. The 
    reasoning was that in IPv6, nodes are required to update their ARP caches if 
    they see a gratuitous ARP, so as long as the newly elected router did a 
    gratuitous ARP, the ARP caches would all get updated, and this approach 
    would avoid having a MAC address move within the topology. Some 
    objected to this because the endnodes would then be aware that the router 
    had switched, but others liked this proposal specifically because the 
    endnode would know that something had happened. There was also concern that 
    if the gratuitous ARP got lost, it might take a long time for ARP caches to 
    get fixed to the MAC adress of the new router. Another argument was that 
    doing things very differently for VRRPv3 than VRRPv2 is out of the 
    charter of the WG. So the conclusion is that we will assume for now that 
    VRRPv3 will continue to use VMACs, but that the issue can be discussed on 
    the mailing list, and if there is a lot of interest and a concrete 
    proposal, we can revive this 

    Slides

    VRRP Working Group
    VRRP Specifications Updates
    Subsecond vrrp timers