2.5.14 Virtual Router Redundancy Protocol (vrrp)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-24

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: http://www.ietf.org/mail-archive/web/vrrp/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
Done  Submit updated version of VRRP (IPv4) for Draft Standard
Done  Decide on the VRRP MIB draft (unified or separated MIBs)
Done  Resolve ND vs VMACs issue with VRRPv3
Oct 04  Submit MIB for VRRPv3 for Proposed Standard
Oct 04  Submit VRRP for IPv6 (VRRPv3) for Proposed Standard
Nov 04  Review the WG goals and future potential
  • - draft-ietf-vrrp-ipv6-spec-06.txt
  • - draft-ietf-vrrp-unified-mib-01.txt
  • Request For Comments:
    RFC2338 PS Virtual Router Redundancy Protocol
    RFC2787 PS Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2
    RFC3768StandardVirtual Router Redundancy Protocol

    Current Meeting Report

    Virtual Router Redundancy Protocol WG (vrrp)

    Tuesday, August 3 at 1415-1515

    CHAIRS: Mukesh Gupta <Mukesh.Gupta@nokia.com>
    Radia Perlman <radia.perlman@sun.com>

    Agenda Bashing Chairs 5 mins

    Current Drafts' status Chairs 5 minutes

    VRRPv3 and IPv6 ND RA Bob Hinden 15 minutes

    Mukesh Gupta - agenda
    vrrp for IPv4 is draft standard now (RFC 3768)

    vrrp for ipv6 there are implementations
    they have raised issues

    vrrp mib: The draft is available and needs to be reviewed.

    Bob Hinden

    no mechanism in ND that insures that hosts send to multiple routers.
    need to insure that backup vrrp routers send all nd options that address owner was sending.
    general question about the use of nd and vrrp.

    Issue 1 - ND Load Balancing
    ND currently doesn't insure that
    IPv6 host to router load sharing


    Resolution of the issue:
    IPv6 load sharing draft provides needed mechanism
    no change is required in vrrpv6

    Need to insure that backup VRRP routers send all ND options that address owner was sending.
    Recommend adding text that makes this requirement clear.
    Require backup router to have address owner option information.

    Bob thinks he is volunteering to look at the ND stuff to look at this to make sure this works.

    General question raised about the use of ND in VRRP
    Issue isn't clear to Bob Hinden

    Radia mentioned that the only possible problem with having all backup routers send all the same options as the address owner is that there might potentially be options that are router specific rather than address specific, for instance, which destination prefixes are best reachable through that router. In that case it might be reasonable to customize the options sent, and have backup routers give different values than the address owner. Bob Hinden volunteered to check with the ND spec to see if there are any such options. This will help clarify whether we should mandate that all backup routers be configured to send the same set of options as the address owner, recommend it, or explicitly not require it.