Let me see I understand correctly.
If mesh-under and multicast adaptation layer then:
ff02::1 maps into 0x8001
ff02::2 maps into 0x8002
Correct.
Else:
ffXX:X:X:X:X:X:X:X map into 0xffff
Correct (for valid values of X).
If yes I disagree with mapping all IP multicast addresses into 0xffff
MAC broadcast, because ff0e::1 global-scoped IP address shouldn't be
sent to link-layer broadcast
That's what 4944 says, though (and it would even work quite well for a
route-over solution with e.g. SMF).
- it may be considered noise.
I don't understand that sentence. Noise is an L1 concept.
How about suggesting IEEE 802.15.4 to use Ethernet's MAC multicast
features? Is there already an IEEE activity doing this?
I don't think we want to suggest IEEE to make the MAC layer *more*
complicated.
PS: there is more error in rfc4944 saying that "IPv6 level
multicast packets MUST be carried as link layer broadcast frames" -
because only the link-local scoped IP multicast packets should, and
not the globally-scoped multicast packets.
This is the non-mesh-under multicast case. No error.
There is an error in sending a global-scoped IP multicast packet to a
link broadcast address - one's neighbors may have not subscribed to
that
global group yet they receive the packet.
In many adaptation layers, including Ethernet, multiple IP multicast
addresses are mapped to one L2 multicast address. Mapping all IP
multicast addresses to one L2 broadcast address is just slightly more
extreme. In any case, you have to filter at L3 as well. (Yes, that's
really ugly with fragmentation, but sending fragmented multicasts is
not very useful on a wireless network in any case.)
It could have also been formulated as a requirement document,
instead of
a hardly implementable mapping method.
Something like: if you need IPv6 to work on this adaptation layer then
the adaptation layer should be link-layer multicast capable - please
design the multicast-capable adaptation layer and tell me the
multicast
addresses you're using so that I can map the IP multicast addresses
onto
them...
I guess this could have solved many problems about non-transitive
single-interface multiple-linkscope routers too.
You lost me completely here, but since we are not redesigning 4944
just yet, I don't think we need to discuss this further right now.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
