> 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
