Re: draft-gundavelli-v6ops-l2-unicast WGLC

[Fred Baker <fred@cisco.com>]

The other truly obvious use case, standard in IPv4 ARP, is when refreshing an ARP/ND entry. You already know the MAC address, the question is whether the guy is still there or not. In IPv4, we (pretty much everybody) unicast the ARP request to the most recent MAC address; it either responds or doesn't. If it doesn't, we broadcast the retransmission. In IPv6, we would unicast the Neighbor Solicit and multicast a retransmission of said request.


On Aug 2, 2010, at 3:24 PM, Wes Beebee wrote:

>> As this draft is changing what has been a fundamental and fixed
>> assumption for a very long time (i.e. layer 3 multicast always equals
>> layer 2 multicast), I think it's important that use cases supporting it
>> are very clear in what they're trying to achieve and why allowing
>> multicast layer 3 addresses maps to layer 2 unicast is the best way to
>> solve those problems. A bit more detail in these use cases would help.
> 
> As I understand it, the use case is a fast RA handover when a link first
> comes up.  They don't want to wait for an NS(DAD) (otherwise they could just
> use the LLA from the NS(DAD) as the RA destination, problem solved) - so
> they want to be able to send packets without having a L3 unicast
> destination.  L3 multicast allows them to do that - but then they need L2
> unicast because they really want to send a unicast packet without the L3
> unicast address.  The L3 multicast address is just being used to make sure
> that the node processes the packet.
> 
> The problem is that this assumption of L3 multicast comes with L2 multicast
> is a very deeply imbedded assumption in current implementations - and it
> would take analysis of the whole box including not only the software, but
> also the hardware, in order to see if this can be supported.  As far as I
> know, the software analysis has been done for some implementations, but the
> hardware analysis has not yet been performed.
> 
> - Wes
> 

http://www.ipinc.net/IPv4.GIF