Subject: [VRRP] RE: VMAC vs ND for VRRPv3

From: [email-masked]
Date: Wed, 3 Dec 2003 17:42:41 -0600

Thanks Don. 

This could have been used this as yet another argument 
for using ND instead of VMACs in the meeting but this is 
still useful to know.

Regards
Mukesh

> -----Original Message-----
> From: ext Don Provan [mailto:[email-masked]]
> Sent: Wednesday, December 03, 2003 3:15 PM
> To: [email-masked]
> Cc: Gupta Mukesh (IPRG/MtView)
> Subject: RE: VMAC vs ND for VRRPv3
> 
> 
> Mukesh asked me to look into whether the problems with ARP
> implementations in IPv4 has been cleared up in IPv6's Neighbor
> Discovery mechanism. (I think he wanted this in time for November's
> meeting...oh, well.) I've finally gotten a chance to look into it.
> 
> First of all, it's very clear that the problem of IPv4 ARP
> implementations ignoring unsolicited MAC address changes was
> understood and addressed in the ND work. RFC-2461 has an entire
> section (7.2.6., "Sending Unsolicited Neighbor Advertisements", p 64)
> describing when and how a node recognizing a change in the MAC layer
> address should convey that information to other nodes in the
> environment. In addition, a careful reading of the previous section
> (7.2.5., "Receipt of Neighbor Advertisements", starting on p 62) will
> ultimately lead one to the fact that an unsolicited advertisement
> MUST update the link-layer address.
> 
> In short, handling MAC address updates is a well specified and
> unmistakable requirement for ND implementations.
> 
> The downside is an ND concept called "Neighbor Unreachability
> Detection". This requires that a newly learned MAC address be
> confirmed reachable. This can be accomplished by an upper layer such
> as TCP seeing an event which tells it that one of its packets has been
> sent over the new path, but it could fall to ND itself to confirm the
> reachability using a unicast solicitation/advertisement exchange.
> 
> So a MAC change might trigger a two packet exchange with all
> neighbors, but reachability has to be confirmed every 30 seconds or
> so, anyway, so the additional traffic triggered by one MAC change will
> be insignificant compared to the background of such exchanges.
> 
> I claim that the old IPv4 ARP problem can no longer be used as a
> justification of the VMAC in VRRPv3. There may still be other reasons
> we might want to use VMACs to keep the burden of changing paths in
> the layer 2 switches, but unreliable ND implementations in layer 3
> components does not appear to be one of them.
> 
> -don provan
> [email-masked]
> 

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