Thanks for enlightening about this.
Carsten Bormann a écrit :
rfc4944 doesn't seem to say a link-local scope multicast address is
mapped into 0xffff, but probably into something like 0x8001.
That depends. Section 9 addressing is explicitly for mesh-under only
(section 9, first sentence) -- if there is an actual multicast
framework under/in the adaptation layer, it was considered useful to
map the L3 multicast addresses to different MAC addresses as well. If
not, all multicast maps to 0xffff broadcast.
Let me see I understand correctly.
If mesh-under and multicast adaptation layer then:
ff02::1 maps into 0x8001
ff02::2 maps into 0x8002
Else:
ffXX:X:X:X:X:X:X:X map into 0xffff
Right?
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 - it may be considered noise.
For example NS is sent to 33:33::1/ff02::1 whereas RS is sent to
33:33::2/ff02::2
We don't use Ethernet's 48-bit MAC addresses in 4944. (Let's try to
focus the discussion on the 6lowpan list to 6lowpan, please.)
How about suggesting IEEE 802.15.4 to use Ethernet's MAC multicast
features? Is there already an IEEE activity doing this?
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.
I disagree doing so.
[...]
Discussing mesh-under multicast is always a bit difficult because
there is no actual system instance to discuss it relative to.
I agree!
One could argue that putting currently unused functionality into 4944
might have been premature, but it might also help commonality of any
mesh-under multicast solutions that arise.
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.
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
