Virtual Router Redundancy Protocol (vrrp) Charter

2.4.6 Virtual Router Redundancy Protocol (vrrp)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 05-Dec-01

Chair(s):

Bob Hinden <hinden@iprg.nokia.com>

Routing Area Director(s):

Randy Bush <randy@psg.com>
Bill Fenner <fenner@research.att.com>

Routing Area Advisor:

Bill Fenner <fenner@research.att.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.

Internet-Drafts:

Request For Comments:

RFC	Status	Title

RFC2338	PS	Virtual Router Redundancy Protocol
RFC2787	PS	Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2

Current Meeting Report

Virtual Router Redundancy Protocol (VRRP) Working Group
Salt Lake City IETF
December 11, 2001

Bob Hinden <hinden@iprg.nokia.com>
Chair

Minutes taken and edited by Bob Hinden

----------------------------------------------------------------------

TUESDAY, December 11, 2001, 1300-1400

AGENDA
-------

Introduction
VRRP (for IPv4) to Draft Standard status
VRRP for IPv6
<draft-ietf-vrrp-ipv6-spec-01.txt>
Other Topics
Charter Update

-----------------------------------------------------------

VRRP (for IPv4) STATUS
o Ready to advance to Draft standards, except
- Need to show evidence of use of IPSEC for authentication
o Choices
- Provide implementation evidence
- Wait until two show up
- Remove IPSEC AH as an authentication mechanism from specification

Reviewed history of moving VRRP to Draft Standard. Discussion on choices. It isn't clear if IESG will accept version without strong authentication. Chair will follow up with area director.

If there are not any IPSEC AH implementations, it may be worthwhile to recycle at proposed standard. The last draft had a number of clarifications that are worthwhile to be published.

VRRP for IPv6
o Work was under original VRRP w.g. charter
o Provide VRRP capability for IPv6
o IPv6 Neighbor Discovery is an improvement over similar IPv4 mechanisms, but
- Doesn't provide for quick switch over to another router

IPv6 NEIGHBOR DISCOVERY
o IPv6 Hosts learn about Default Routers via Neighbor Discovery Router
Advertisements
- Not sent frequently enough to detect router failures
o ND Neighbor Unreachability Detection used to detect router (or host) failures
- 38 seconds using default parameters
- 5 seconds by adjusting parameters, with significant more host-router traffic

DEFAULT ROUTER LOAD SHARING
o Neighbor Discovery doesn't require hosts to distribute traffic when
there is more than one default routers
- Using single default is allowed
- Allows round robin selection
o This is addressed in "IPv6 Host to Router Load Sharing" draft
<draft-hinden-ipv6-host-load-sharing-01.txt>

VRRP for IPv6 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 | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Adver Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CHANGES FROM VRRP (for IPv4)
o Increment VRRP version to 3.
o Change packet format to support an 128-bit IPv6 address.
o Change to only support one router address (instead of multiple addresses). This included removing address count field from header.
o Rewrote text to specify IPv6 Neighbor Discovery mechanisms instead of ARP.
o Changed state machine actions to use Neighbor Discovery mechanisms. This includes sending unsolicited Neighbor Advertisements, Receiving Neighbor Solicitations, joining the appropriate solicited node multicast group, sending Router Advertisements, and receiving Router Solicitations.

OPEN ISSUES
o Remove IPR section?
o Remove IPSEC AH authentication?
o Replace AH w/ VRRP Specific MD5 authentication

Long discussion on the IPR issue. General consensus to remove the IPR section in the VRRP for IPv6 draft as there have not been any claims made about this draft.

There was also discussion about the need to get the companies who made claims against VRRP (for IPv4) to drop them to allow VRRP to be implemented by the open source community. Someone from Cisco said they would raise this topic inside of Cisco.

Need to discuss with the Routing AD the best approach on how to handle strong authentication. It may be that the IESG view on IPSEC has changed somewhat since VRRP (for IPv6) was developed.

NEXT STEPS
o Did anyone read draft?
o Ready to advance?

Several people had read the draft. Consensus to continue working on VRRP for IPv6. New draft will be needed to issued to resolve open issues.

OTHER TOPICS
o Working Group Charter
- Milestones need to be updated

The milestones in the charter need to be updated. Chair will take a cut at this and send to the mailing list for the w.g. to review.

Bill Fenner also raised the issue of a VRRP for IPv6 MIB. They could be an update to the existing MIB or a new MIB. People interested in working on this should contact the char.

--------------------------------------------------------
Meeting Adjourned
--------------------------------------------------------

Slides

Agenda