2.5.11 Virtual Router Redundancy Protocol (vrrp)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


Bob Hinden <hinden@iprg.nokia.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>

Routing Area Advisor:

Rob Coltun <rcoltun@siara.com>

Mailing Lists:

General Discussion:vrrp@drcoffsite.com
To Subscribe: listserv@drcoffsite.com w
In Body: subscribe vrrp <your_name>
Archive: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*

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" 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:

Jun 97


Charter Working Group

Jul 97


Issue new Internet Drafts for IPv4 version of the protocol.

Aug 97


Issue Internet Draft for IPv6 version of VRRP.

Aug 97


Review and finalize IPv4 Internet Drafts.

Aug 97


Resolve any intellectual property issues regarding protocol.

Sep 97


Submit revised IPv4 Internet Drafts to IESG for proposed standard.

Oct 97


Issue VRRP MIB drafts.

Oct 97


Issue revised draft for IPv6 version of VRRP.

Dec 97


Review and finalize IPv6 Internet Drafts.

Dec 97


Finalize MIB draft and submit to IESG.

Jan 98


Submit revised IPv6 Internet Drafts to IESG for proposed standard.


Request For Comments:







Virtual Router Redundancy Protocol

Current Meeting Report

VRRP Minutes - 46th IETF, Washington, D.C., 11/9/99
Bob Hinden - Chair

Minutes taken by Barbara Denny



Review Agenda

Status of VRRP to Draft Standard

Presenter: Bob Hinden (Nokia)

VRRP now conforms to a new boilerplate. The IESG also had comments on the authentication method used in VRRP. Even though we were directed to use IPSec MD5 in the draft, no one has implemented it. This raises a process question since we cannot promote a document to Draft Standard with features we have not implemented. Choices are to take it out or put it in a separate specification. The customer environments for VRRP do not really require strong security so the current plan is to push on the area directors to see if we can take that 3rd method of authentication out. The working group chair has not heard back from the IESG yet.

[NOTE: Subsequent to the VRRP meeting, the IESG discussed the issue and decided that VRRP will need to show interoperability of two VRRP implementations using AH before it can be promoted to Draft Standard.]

Status of VRRP MIB to Proposed Standard

There has been a lot of discussion with the Network Management Area Director. At the time of the meeting, no new input from the area director has been received but this needs to be checked.

Summary of Changes to VRRP MIB Draft

Presenter: Brian Jewell (3Com)

A new draft has been produced since the previous Oslo draft. Most of the changes involve modifications to the descriptions. The traps were also changed: the OIDs and the objects were changed. The draft now also conforms to new MIB conventions. The current draft maintains an extensive log of the changes. No questions were asked regarding the MIB and no new changes are anticipated. Once we hear back from the NM AD, the plan is to issue working group last call on moving the document to Proposed Standard.

Summary of Changes to VRRP Over ATM LAN Emulation

Presenter: Atul Bansal (Laurel Networks, Inc. previously at FORE)

A new draft was not submitted in time for this meeting but there are some changes. A new draft needs to be issued. This will probably be done in about a week. The plan is the issue a working group last call on this draft for Proposed Standard once the draft is released.

The changes from the previous version of the draft include:

This was added to deal with the non-proxy case. There was a problem when the LEC or master died. The binding was kept between the VMAC and ATM address.

This was because a lot of corner cases were not covered so the decision was to drop this section.


The VRRP specification got recognition from Steve Bellovin for its' discussion of security considerations in <draft-rescorla-sec-cons-00.txt> that provides guidelines for writing security considerations in internet protocol standards. This draft has a few comments for improving the vrrp specification so since the draft is open, the working group chair will try to address his concerns.

The working group chair proposed that the working group plan to go into hibernation once the VRRP specification is at Draft Standard and the MIB and LANE documents are at Proposed Standard. The group will wake up when the MIB and LANE document are ready to be considered for Draft Standard. This was no objection to this.


None received.