VRRP Minutes - 39th IETF, Munich, 8/15/97 Bob Hinden - Chair Minutes taken by Barbara Denny Agenda: Introduction Review of changes Security Token Ring HSRP Report Intellectual Property Issues Status Digital Approach Comparison Decision to Move to Standard MIB IPv6 Introduction ------------ On June 12th, the working group charter was approved. The Goals and Milestones for this working group are: Jun 97 Charter Working Group Jul 97 Issue new Internet Draft for IPv4 of the protocol. Aug 97 Issue Internet Draft for IPv6 version of VRRP. Aug 97 Review and finalize IPv4 Internet Draft. Aug 97 Resolve any intellectual property issues regarding protocol. Sep 97 Submit revised IPv4 Internet Draft 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 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. 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 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 3 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. 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 3 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. HSRP Report ----------- Phil Morton reported that he is responsible for "the care and feeding" of HSRP at Cisco. An internet draft of the protocol has been submitted . 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. 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 which 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). 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 or Peter Higginson . 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, use 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 switch-over 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. 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. 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. MIB --- Barbara Denny volunteered 3Com to write an IPv4 MIB for VRRP. 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.