Subject: Re: [VRRP] Virtual MAC for IPv6

From: "M. T. Hollinger" <[email-masked]>
Date: Fri, 15 Aug 2003 18:35:45 -0400

Bob, I think we will have to agree to disagree on this issue.

I continue to believe that support for duplicate MAC addresses places
additional constraints on the underlying data-link layer, creating potential
restrictions or incompatibilities for VRRP as new IEEE 802 variants emerge
or switch vendors develop new optimizations for traditional Ethernet links.
Moreover, hiding the identity of the current router may complicate
troubleshooting and keep "smart" workload management software on end hosts
from noting and responding to network failures.

To me, the argument that virtual MAC addresses have worked satisfactorily in
the IPv4 VRRP world is not compelling.  As I said in Vienna, NAT may be
deployed and proven technology in the IPv4 world too, but that should not
prevent us from considering architecturally cleaner designs as we move
toward IPv6.

In general, layer violations should be avoided because they introduce
complexity and constraints.  As someone who has experience with DECnet Phase
IV, I have become painfully aware of the pitfalls of having upper-layer
protocols override the hardware MAC address.  Even without the added
complication of suddenly moving the virtual MAC address to another part of
the network, simply using a physical MAC address different from the hardware
address brings confusion and dependencies.

As you (Bob) pointed out, the picture gets even more complicated when
considering subsecond timers and the goal of very fast failover.  How
quickly will your switches learn the new location of the router's VMAC
address, and propagate their spanning tree data throughout the extended LAN?
If it takes VRRP 3 seconds to initiate failover and your switches another 3
seconds, is that acceptable?  Users who want fast failover will have to shop
around for switches that respond quickly to movement of a unicast MAC
address.

On the other hand, if you get rid of VMAC, you eliminate the dependency on
switch behavior.

             - Mark

----- Original Message ----- 
From: "Bob Hinden" <[email-masked]>
To: "M. T. Hollinger" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 15, 2003 11:02 AM
Subject: Re: [VRRP] Virtual MAC for IPv6

Mark,

At 06:52 AM 7/15/2003, M. T. Hollinger wrote:
>The vrrp-ipv6-spec-05 draft still specifies the use of virtual MAC
>addresses, even with IPv6.
>
>I have long disliked the use of duplicate MAC addresses for v4, which was
>justified with the argument that some older ARP implementations did not
>properly receive and parse gratuitous ARP messages.
>
>That argument does not apply to IPv6.  I oppose moving this document
forward
>until the use of virtual MAC is removed.  (Alternatively, if there is a
>strong justification, then text could be added to the document explaining
>why this architecturally awful design was believed to be the best choice
for
>the IPv6 environment.)

I don't agree that it is so bad or as you say an "architecturally awful
design".  I have thought about it as one of the great MAC address hacks :-)

The advantage of this approach is that it works without the hosts having to
do anything (e.g., receive and process an ND message, update tables,
etc.).  The switch over is transparent to the hosts.

This approach is well proven in the IPv4 version of VRRP.  It is running
operationally in many places and I am not aware of any problems.  Are you
aware of any technical problems with the virtual MAC address approach?

Thanks,
Bob

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Don Provan" <[email-masked]>
Date: Wed, 20 Aug 2003 10:48:52 -0700

I wanted to weigh in *against* the artificial, shared MAC
addresses, too. Contrary to Bob's assertion, I found them
a significant problem even in IPv4, well worth avoiding
if there's any possibility. One problem I've previously
brought up here is the one switch I ran into that dropped
any packet that changed a learned addresses. This resulted
in a ping-pong problem where two routers would both be
happily sending advertisements once a second yet never
hearing one another. (My implementation routinely sends
two advertisements at a time, one using the natural MAC
address as the source, just to make sure this isn't a
problem.)

But even beyond that, I found that during development,
implementation problems could lead to strange problems
that were hard to diagnose. Some problems were hard
to even detect. For example, one switch had a configuration
parameter that caused it to interpret the duplicate MAC
address not as a move, but as extending the MAC address
to two links. Then it would happily send traffic for
that MAC down both the links, wasting bandwidth on the
link that was no longer supporting the VR.

Originally I saw the VRRP MAC address as a clever trick
to provide maximum support for even the stupidest of
remote nodes. But now that I've encountered such a wide
range of reactions by modern switches, I'm not so sure
I think it's a good idea in IPv4, let alone in IPv6.

-don

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of M. T.
> Hollinger
> Sent: Friday, August 15, 2003 3:36 PM
> To: [email-masked]