===================VRRP 7/16/2003
Milestone review
New milestones were proposed.
===
Mar 2003 - Resolve open issues with authentication methods [DONE MAR 2003]
Aug 2003 - Submit updated version of VRRP (IPv4) for Draft Standard
Oct 2003 - Submit VRRP for IPv6 (VRRPv3) for Proposed Standard
Dec 2003 - Submit MIB for VRRPv3 for Proposed Standard
Dec 2003 - Review the WG goals and future potential
===
VRRPv3 MIB
There was a discussion about whether there should just be a single
combined MIB for IPv4 and IPv6, or whether there should be two, and if
there were two, one should be IPv4-only, but should the other be
combined IPv4 and IPv6, or IPv6-only. The current draft is assuming
IPv4-only plus IPv6-only. The conclusion was that it might be good to try to
do a strawman IPv4+IPv6 and see if that works well. One argument for why
there couldn't be a single MIB was that VRRPv2 is stable while VRRPv3 is
still evolving, and there ought to be a stable MIB to go along with the
stable protocol. Another is that VRRPv2 and VRRPv3 might be
sufficiently different protocols that it would be confusing to try to
combine them.
VRRPv2 spec update
Bob Hinden presented the changes to VRRPv2, which were mostly
editorial other than removing the authentication methods, and adding to the
security considerations section an explanation for having done so. An
issue was raised about having too many listed authors, and some
obsolete addresses for them. The conclusion was that Bob Hinden should be
listed as "editor", and a "contributors" section should be added
acknowledging the others. There was an issue that had been raised on the
mailing list about possible pathological behavior when multiple backup
routers had equal priorities, and on the mailing list a suggestion had been
made for adding a tie-breaker based on IP address. After discussion
during the meeting, it was concluded that the particular section of code
involving backup router ties would not be invoked, because a router, once it
sends a VRRP message, has already decided it is master, and the master
portion has the IP-address tie-breaker. So the conclusion was that the
election logic was fine as is. The sense of the room was that VRRPv2 is
ready for wg last call.
Sub-second Timers
Karen O'Donoghue gave a presentation explaining the need for faster
convergence (less than one second) than could be done using timers in
units of seconds. The sense of the room was that they were convinced of the
need, at least for IPv6. It would be difficult to do it for IPv4 because it
would be an incompatible change, and it would be undesirable to delay the
specification. Various encoding techniques were described, the most
straightforward being making the size of the timer field longer and the
units smaller (perhaps 100 ms), and other suggestions involving
exponential encoding so as to fit into the same sized field. The
conclusion was to pursue this on the mailing list for v6, and if it is
desired for IPv4, to have a new draft for a new version of VRRP for IPv4
(perhaps version number 4). A quick check was made to ensure that VRRPv2
does indeed say that a VRRPv2 router should drop VRRP messages with
unknown version numbers, which is required in order to safely roll out a new
version of VRRP.
VRRPv3
As with v2, removed authentication types and added explanation in
security considerations section.
An issue from the mailing list was discussed, which is that using VMACs
causes layer 2 addresses to change locations, which is somewhat
dangerous in a bridged LAN. For IPv4, VMACs are necessary because there are
implementations of hosts (e.g., Win 95) that do not update their ARP
caches when they receive gratuitous ARP messages. But the question was
raised as to whether VMACs, and perhaps even VRRP, could be avoided for
IPv6.
The conclusion about whether VRRP for IPv6 could be avoided was that it
could not. VRRP for IPv6 could not be avoided because the neighbor
discovery mechanism in IPv6 would not be able to react to changes as
quickly as a mechanism such as VRRP, confined to a community of a few
routers. And even if IPv6 neighbor discovery could in theory be
modified to be as responsive as VRRP, the VRRP WG could not impose
changes to a different WG.
The second issue was whether VMACs could be avoided for IPv6, i.e., have
VRRPv3 still elect one router to represent the IP address, but not move MAC
addresses. The elected router would use its own MAC address. The
reasoning was that in IPv6, nodes are required to update their ARP caches if
they see a gratuitous ARP, so as long as the newly elected router did a
gratuitous ARP, the ARP caches would all get updated, and this approach
would avoid having a MAC address move within the topology. Some
objected to this because the endnodes would then be aware that the router
had switched, but others liked this proposal specifically because the
endnode would know that something had happened. There was also concern that
if the gratuitous ARP got lost, it might take a long time for ARP caches to
get fixed to the MAC adress of the new router. Another argument was that
doing things very differently for VRRPv3 than VRRPv2 is out of the
charter of the WG. So the conclusion is that we will assume for now that
VRRPv3 will continue to use VMACs, but that the issue can be discussed on
the mailing list, and if there is a lot of interest and a concrete
proposal, we can revive this
|