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

From: Wes Beebee <[email-masked]>
Date: Mon, 02 Aug 2010 09:24:57 -0400

> 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

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 02 Aug 2010 15:55:16 +0200

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

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 Aug 2010 20:54:33 +0200

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.

> hardware analysis has not yet been performed.

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