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

[Wojciech Dec <wdec@cisco.com>]

On 02/08/2010 15:24, "Wes Beebee" <wbeebee@cisco.com> 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.

That is not quite so. There are numerous L2 protocols that do not map a L3
mcast to L2, eg PPP. One could even say PPPoE. The technique has been used
for years in Wifi 802.11 too, besides regular IPv4 over ethernet which is
implied as the only L2 here.

> 
> 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.

- (as mentioned) The technique has and is being used (broadly) for IPv4 over
ethernet There is nothing that is in IPv6, or IPv4, specs which makes such a
check required
- There is no known good reason why an implementation should check (at sw or
hw) that an L2 frame containing an L3 *mcast* packet with a matching L2
*mcast* address. As such, if in some nook or cranny there is a device doing
this sort of thing in hw or sw, i.e. it's likely a bug.
You're welcome to point us to any documented cases where usage of such a
"check" is necessary. Until these are revealed, there is hardly a case for
requesting more "analysis"

-Woj.




> 
> - Wes
> 
>