NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Bob Hinden <hinden@ipsilon.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Routing Area Advisor:
Joel Halpern <jhalpern@newbridge.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 multi-access 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:
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:
· Virtual Router Redundancy Protocol
No Request For Comments
Minutes of the VRRP WG Meeting
Chaired by Bob Hinden
Reported by Barbara Denny
Agenda
I. Introduction
II. Review of changes
III. Security
IV. Token Ring
V. HSRP Report
VI. Intellectual Property Issues Status
VII. Digital Approach
VIII. Comparison
IX. Decision to Move to Standard
X. MIB
XI. IPv6
I. Introduction
On June 12th, the working group charter was approved. The Goals and Milestones for this working group are:
1. Jun 97 Charter Working Group
2. Jul 97 Issue new Internet Draft for IPv4 of the protocol.
3. Aug 97 Issue Internet Draft for IPv6 version of VRRP.
4. Aug 97 Review and finalize IPv4 Internet Draft.
5. Aug 97 Resolve any intellectual property issues regarding protocol.
6. Sep 97 Submit revised IPv4 Internet Draft to IESG for proposed standard.
7. Oct 97 Issue VRRP MIB drafts.
8. Oct 97 Issue revised draft for IPv6 version of VRRP.
9. Dec 97 Review and finalize IPv6 Internet Drafts.
10. Dec 97 Finalize MIB draft and submit to IESG.
11. Jan 98 Submit revised IPv6 Internet Draft to IESG for proposed standard.
Current status with respect to this schedule is there is no IPv6 draft. The approach is now to postpone this draft until we agree on the IPv4 version.
II. Review of Changes
The changes made to the VRRP protocol from the previous version are:
· Added preempt mode
· Expanded security
· Expanded state description and removed state table
· Changed authentication to be per interface, not per cluster
· Clarified text on ICMP redirect
· Added text on FDDI
· Added HSRP acknowledgment
· Many small text clarifications
III. Security
Bob Hinden asked Steve Bellovin to review the VRRP specification. Steve indicated that the authentication approach in the current specification is fine. There are three levels of authentication:
· No authentication
· Simple text - provides no protection against eavesdropping
· Authentication header - use in a more open environment
The working group asked that some clarifications be made to the text. First be explicit about the security mechanism. The specification should specify HMAC-MD5; don't just say HMAC. The security here stops someone from accidentally plugging in a router, nothing more. Also, point to the most recent security specification when done.
IV. Token Ring
The current VRRP specification doesn't work with Token Ring. The problems include:
1) No multicast - could use functional addresses but they are not unique so you could have collisions
2) Limited ability to receive multiple MACs
3) TR source routing bridges
The working group needs to decide whether VRRP needs to run over token ring.
There was a suggestion to add an appendix for token ring. Cisco wants it to work over token ring and claims HSRP works over token ring. The question was asked regarding what allows Cisco to run over token ring. HSRP allows up to three clusters. They use functional addresses but mentioned that one of those addresses collides with PIM. There may be a chance to use hardware MAC address. There was some discussion of whether to use gratuitous ARP. DEC mentioned they have experience in this area and don't recommend using it because of the host behavior. It doesn't work reliably. There was no real consensus on the issue but Joel Halpern suggested we consider this protocol for legacy and broadcast media environments.
A volunteer is needed to help draft appropriate token ring text in the specification.
V. HSRP Report
Phil Morton <pmorton@cisco.com> reported that he is responsible for "the care and feeding" of HSRP at Cisco. An internet draft of the protocol has been submitted <draft-li-hsrp-00.txt>. HSRP is functionally equivalent to VRRP except for security. The protocol is running in many customer sites and a MIB is in the works. Even though Cisco has a patent, the intent of the patent is not to preclude others from using HSRP. Cisco wants interoperability.
VI. Intellectual Property Issues
Following the report, a discussion ensued regarding the patent issue. Someone from Ascend stated that they have a protocol very similar to HSRP and Cisco sent them a "cease and desist order", and threatened to sue. Ascend has removed the protocol from their product. It was brought up that patents are on technology not protocols. Joel Halpren stated that Cisco has indicated that they plan to commit to a license that is fair and non-discriminatory basis "for performing the standard." Cisco currently does not plan to do anything more until the specification reaches proposed standard. If things go wrong, the working group can go back to square one but for now, the working group should assume good faith on the part of Cisco and continue and see what happens.
Bob Hinden mentioned that he recently looked at the patent. The patent Cisco has that may apply is patent number 5,473,599. It was issued on December 5, 1995. The URL of a good website for looking up patents is http://patent.womplex.ibm.com. One key differentiator may be use of a "coup message" that exists in HSRP but is not in VRRP. Each implementor will have to decide for themselves. A patent infringement occurs when you ship product.
The discussion also included some comments regarding the general approach the IETF is taking with regards to patents. It appears to be that it is up to the individual/company to resolve any problems with releasing a product that has a patent issue. The IETF will not determine if a patent applies nor will the IETF try to determine what is fair and non-discriminatory. A working group may adopt a draft as a proposed standard if it is unencumbered or there are assurances of licensing (e.g. OSPF has two patents regarding it).
VII. Digital Report
Peter Higginson presented Digital's protocol for Virtual Router Clusters. It has been supported by DECNIS routers since the fall of 1994. Details on the protocol have been submitted to a "Digital Technical Journal" paper. Copies of this paper are available if you send mail to Mike Shand <shand@mail.dec.com> or Peter Higginson <higginson@mail.dec.com>.
Briefly, the Digital protocol is solving the same problem. When a router fails, traffic from hosts is handled by another router without host action. There is also an election that is similar to the IS-IS routing protocol. An elected primary is responsible for forwarding traffic for failed routers. The protocol does have a notion of priority with respect to which router will take over for a failed router.
The major differences from VRRP are:
· All routers continue to route using their normal IP addresses (including multiple subnets)
· ICMP redirects continue to operate normally!
· All mechanisms for hosts finding out about routers still work (If a default gateway needed, any router in the cluster will do).
To achieve this, each router always receives IP traffic on a Virtual MAC address. The elected primary forwards traffic for any failed routers and answers ARPs on their behalf. Virtual MAC address is used for sourcing hello packets and for ARP. Control traffic, such as in routing updates, uses the real MAC address.
The minor differences are:
· Each router effectively becomes the master of it's own cluster and backup for the other clusters.
· Election algorithm is non-sticky (easy to change)
· Authentication could be added
· Uses UDP encapsulation of the hellos (to a port registered as digital-vrrp)
· Hellos are sent to the "all routers" multicast with a TTL of 1
· Hellos are sent by all routers because:
- All routers are active
- Hellos sourced with the routers virtual MAC address
The goal of the protocol is to achieve switchover in under 5 seconds.
Several diagrams were presented that depict different scenarios for the protocol operation. These diagram stress the need to preserve router redirect and include instances where you can't configure hosts with a default gateway but yet would like the protocol to help you.
Digital does not have a patent on their work because they felt it was too close to other things to patent it.
VIII. Comparison
The key difference between VRRP and HSRP, and Digital's scheme, is authentication. HSRP has a password field, including a default value, which translates to "cisco," for the installation of parameters, but there is no other form of security. Security is critical because it provides a useful function and the IESG is now insisting that all new protocols include appropriate security mechanisms. A comparison regarding the level of complexity and amount of control traffic shows that HSRP is not as lightweight as VRRP; however, the differences are not large. All protocols presented have been implemented by at least one vendor. The ability to preserve the ICMP redirect function is highly desirable.
XI. Decision to Move to Standard
There was a consensus from the working group that VRRP will become the baseline specification for moving to proposed standard. The working group will investigate use of real IP addresses because it supports use of ICMP redirects. Retaining ICMP redirects is an important feature. Peter Higginson volunteered to help the VRRP authors with any necessary changes.
X. MIB
Barbara Denny volunteered 3Com to write an IPv4 MIB for VRRP.
XI. IPv6
As mentioned earlier, the decision to write a VRRP spec for IPv6 has been delayed pending the outcome of the VRRP/HSRP decision. The question was asked if VRRP is really necessary in IPv6 or do the existing IPv6 neighbor discovery mechanisms suffice.
VRRP - Status (Goals, Documents, etc.)