2.5.9 Virtual Router Redundancy Protocol (vrrp)

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

Last Modified: 2003-01-14

Chair(s):
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>
Technical Advisor(s):
Radia Perlman <radia.perlman@east.sun.com>
Mailing Lists:
General Discussion: vrrp@ietf.org
To Subscribe: vrrp-request@ietf.org
In Body: subscribe vrrp
Archive: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*
Description of Working Group:
Note: Radia is the Security Technical Advisor.

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 bgraphics/ups 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:
JUN 97  Charter Working Group
JUL 97  Issue new Internet Drafts for IPv4 version of the protocol.
AUG 97  Resolve any intellectual property issues regarding protocol.
AUG 97  Issue Internet Draft for IPv6 version of VRRP.
AUG 97  Review and finalize IPv4 Internet Drafts.
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  Finalize MIB draft and submit to IESG.
DEC 97  Review and finalize IPv6 Internet Drafts.
JAN 98  Submit revised IPv6 Internet Drafts to IESG for proposed standard.
MAR 03  Resolve open issues with authentication methods
MAR 03  Submit updated version of VRRP (IPv4) for Draft Standard
MAY 03  Submit VRRP for IPv6 (VRRPv3) for Proposed Standard
JUL 03  Submit MIB for VRRPv3 for Proposed Standard
DEC 03  Review the WG goals and future potential
Internet-Drafts:
  • - draft-ietf-vrrp-spec-v2-06.txt
  • - draft-ietf-vrrp-ipv6-spec-03.txt
  • Request For Comments:
    RFCStatusTitle
    RFC2338 PS Virtual Router Redundancy Protocol
    RFC2787 PS Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2

    Current Meeting Report

    Subject:
    Minutes and Slides for VRRP WG Session.
    From:
    Mukesh.Gupta@nokia.com
    Date:
    Mon, 24 Mar 2003 20:01:42 -0600
    To:
    <minutes@ietf.org>
    
    VRRP Working Group Minutes
    IETF 56 San Francisco, CA, USA
    March 20th 2003.
    
    Chair: Mukesh Gupta
    
    Meeting Minutes Reported by Jeffery Hass. Modified/Formatted by Mukesh 
    Gupta.
    
    Mukesh presented the Agenda and Milestones/Plans. (See the slides)
    
    Security Issues:
    -------------------
    Mukesh presented the summary of security problem and the proposed 
    solution.
    
    everyone was in favor of removing security. No one was in favor of 
    keeping it.
    
    Then the question was how to remove it so that we don't have bgraphics/ward 
    compatibility issues. 
    
    Bob: We should deprecate the authType values other than 0.
    
    Bill Fenner:
    We should do what the implementations do when there is no security 
    present?
    Reccomend turning off security on the other implementations.
    
    Radia:
    We arent' really removing stuff from the headers and just making them 
    reserved?
    
    Mukesh:
    If the authentication is non-zero, drop the pgraphics/et?
    
    Radia:
    Its no different than if somone misconfigured it its no different than 
    wrong password. So just notify the administrator for this.
    
    Mukesh:
    There is a MIB object for this. We could use it.
    
    Radia: 
    This should be brought to the attention of the operators.
    
    Mukesh: Do we need to recycle it through PS again?
    
    Bob: As we are removing security that was stopping it to go to DS, we 
    should just go to DS after removing security.
    
    Mukesh:
    The MIB (2787) will need to be updated for this. Should we remove the 
    security related object from the MIB ?
    
    Bill Fenner:
    They should to be deprecated.
    
    Mukesh:
    The mib will be updated.
    
    vrrpv3:
    ----------
    Mukesh: The security things can be removed completely from here.
    
    Bob: Kame/tahe folks have an implementation?
    
    Mukesh: Yeah but it is just one implementation and we should remove these 
    things before we start seeing more implementations.
    
    Who has read the draft?
    Bob and Radia.
    
    Anyone planning on implementing this?  No.  In the future?  No.
    
    Before we can move to proposed standard, we need at least one.
    
    Radia:
    Why would people have implemented this for v4 than v6?
    
    Tony:
    v6 stuff just lags.
    
    mukesh: should we just wait?
    
    Bob:
    This isn't a routing protocol?
    
    Bill F:
    Its in the routing area.
    
    Its not clear if the rfc 1264 applies.
    
    "I don't like having rules that I am applying ad-lib".  If this applies on 
    routing protocols, then we can use the rfc 2026 rules.
    
    Tony:
    In the past when we chartered the working group - its a one-hop routing 
    protocol.
    
    Radia:
    A case can be made that something a router does is a routing protocol.  
    *laughs*
    
    Mukesh:
    The draft will expire in June.
    
    Bob:
    Security changes should be made no matter what. So that will give us 6 more 
    months. He will talk to the KAME folks about implementations.
    
    vrrpv3 mib:
    --------------
    Its needed at least in drafts.
    Some people have started working on it.
    Will write a new draft instead of updating the existing one. (RFC 3291 has 
    the reason)
    Draft will be submitted to the WG soon.
    Please review it!
    
    IPR Issues (Cisco)
    ---------------------
    We found the following statement from Robert barr
    
    http://www.in-addr.de/pipermail/lvs-user
    s/2001-November/004135.html
    (excerpt)
    essentially, Cisco will use it as a defensive patent only.
    
    IPR Issues, IBM:
    
    Brian Carpenter:
    "don't shoot the messenger"
    "I haven't read any of the documents"
    "I do it for IBM.
    I cannot clarify the disclosure about patent (mumble).
    Attempting to get clarification about this.
    I have become aware of another US Patent 6148410 that may affect VRRP.
    IBM will provide a disclosure of their position on the patent."
    He has expectations that IBM would provide non-discriminatory 
    licensing.
    
    So, we now have 3 patents to worry about.
    
    Are we interested in:
    ------------------------
    -- IPsec AH security for VRRP draft?  
    
    Radia:
    We will have the same problem in the other security section.  
    Misconfiguratinos will yield two masters.
    If we are merely preventing bad guys from doing vrrp, you aren't 
    preventing them from doing maximal harm.
    What kind of threat are we dealing with that this would solve?
    
    Mukesh:
    Some people on mailing list were interested in some form of security.
    
    Bill F:
    In any work that happens, we would like to see something that covers more of 
    the underlying issues.  Some of these aren't within our domain - mac 
    address of VR, for example.  Learning bridges will think the router is 
    "over towards you".  Its not in our space.  Its a much worse problem than 
    two masters.
    
    Mukesh:
    Most people think we shouldn't work on this.  He will confirm on mailing 
    list.
    
    -- Removing priority value 0 - hold election now option?
    
    j: why are we removing this?
    
    r:
    it harms
    only speeds thins up for case where you know you're going down.
    
    Jeff:
    This helps for graceful restart situations.
    
    Bill:
    Graceful restart is often wants to keep forwarding?  We wont want to do 
    this.
    
    Why is 1 not dangerous?  Any priority lower than the master is 
    similarly dangerous.
    
    Bob:
    There are nastier ways to be evil. This wont help security by removing it.
    
    Mukesh:
    Who thinks we should keep?  Most people.  No one voted for removing it.
    
    -- Issus and arguments document ?
    Radia says we should write this.  Basically lets us encode history.
    Who thinks this would should be useful?
    
    Bill: Do we remember enough of the history?
    
    Radia: Its useful even if we don't get all of the issues.
    
    Support is a few, but not enthusiastically.
    
    No opposition to it.
    
    Radia: I will liely be writing this with some help.  If anyone can 
    provide her with help on issues, that'd be good.
    Mukesh: Bob would be good for that.
    
    - Anything else?
    Mark H from HP
    I never liked using the duplicate MAC address.  Why aren't we using 
    unsolicited arps.  Because it wont update their cache in some 
    implementations.  Is this really important in ipv6?  Surely there is a 
    better answer.  Do we have to make the same mistake for v6.
    
    Tony:
    First we did router discovery, not!  Then we did this hgraphics/ for hsrp.  With 
    v6, we have a clean slate.  We could simply insist people implement 
    router discover.  Its the way it should have been.
    
    Radia:
    Bridges really don't like duplicate macs, it makes her uneasy.  If 
    unsolicited arps got lost, then you'll end up with lost or 
    blgraphics/holes.
    
    Bob:
    v6 drafts - the goal was to do the switchover quickly.  He agress with tony 
    that the v6 nodes will hear router advertisements.  With the timers for 
    neighbor advertisements and router discovery, it may not be fast enough for 
    tcp connections to stay up.  it might be worth looking at again.  All v6 
    nodes will listen to these types of pgraphics/ets, maybe that is a better 
    mechanism.
    
    When I was writing this draft, he asked "do we need this at all?" and 
    wasn't able to convince himself.
    
    THE END
    

    Slides

    Agenda