[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-vrrp
Subject:    RE: [VRRP] Virtual MAC for IPv6
From:       "Don Provan" <dprovan () bivio ! net>
Date:       2003-08-27 23:14:20
Message-ID: 001101c36cf0$f2eac990$8918a8c0 () corp ! networkrobots ! com
[Download RAW message or body]

I'm not up on modern IPv6. Could we have a review of the problem?
Are you saying that there is no IPv6 equivalent to the unsolicited
ARP that can be used to inform the network that an IPv6 address
has moved to a new MAC? Surely they didn't make that mistake when
we had so much trouble with this issue in IPv4 -- independently
of any VRRP issues -- even though the ARP spec unambiguously
described the correct behavior to make it work.

Anyway, to return to your question, if there's a flaw in IPv6
that makes it difficult to move an v6 address, I'm OK with
continuing the MAC sharing idea. But keep in mind that, so
far as anyone's been able to determine, the 802.x specs simply
do not say what happens when a MAC address physically moves,
so implementations have quite a bit of leeway in exactly what
they do. So if we really think this is how we want to deal with
the problem, we should probably work on getting 802 to define
what correct behavior is when a switch encounters this event.

-don

> -----Original Message-----
> From: Radia Perlman - Boston Center for Networking
> [mailto:Radia.Perlman@Sun.COM]
> Sent: Wednesday, August 27, 2003 1:18 PM
> To: vrrp@ietf.org; dprovan@bivio.net
> Cc: MyTH@ucx.lkg.dec.com
> Subject: RE: [VRRP] Virtual MAC for IPv6
>
>
> Don and Mark (and anyone else who finds virtual MACs scary)...
>
> Is there an alternative proposal that would avoid it?
>
> At this point there are two possibilities:
>
> a) someone proposes an alternative that works fine with minimalist
> IPv6 nodes as currently specified. If this is the case, then we
> can compare it with virtual MACs and the WG can decide which approach
> is best
>
> b) we come to the conclusion that no solution exists, given IPv6
> neighbor discovery as currently specified.
>
> If what happens is b), then there are two choices:
>
> b1) convince the IPv6 ND working group to modify IPv6 ND
>
> b2) live with virtual MACs.
>
> *******
> So what do we believe is the case here?
>
> Radia



_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp



[prev in list] [next in list] [prev in thread] [next in thread]