Last Modified: 2003-01-14
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.
|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|
|RFC2338||PS||Virtual Router Redundancy Protocol|
|RFC2787||PS||Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2|
Subject: Minutes and Slides for VRRP WG Session. From: Mukesh.Gupta@nokia.com Date: Mon, 24 Mar 2003 20:01:42 -0600 To: <firstname.lastname@example.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