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 <
[email protected]> 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.
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 <
[email protected]> or Peter Higginson
<
[email protected]>.
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.
