Carsten Bormann a écrit :
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).
Ok, I agree on this interpretation, thanks for clarification.
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.
Ok, noise is an L1 concept.
At L3 what I've seen reported in the past is "ARP storm" over
non-multicast capable Ethernet links (with broadcast address 0xffffffff)
which disappeared when multicast-capable addresses (33:33:x:x:x:x)
started to appear, together with the MUST join a group before receiving
data from it, and used extensively by ND.
ND using 0xffff addresses, and nodes free from the requirement to join
groups, looks as a return to the past and its inefficiencies, maybe risk
of "LoWPAN ND storm".
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.
How about suggesting 802.15 subgroups to re-use the 802.3 MAC layer, as
802.16 did. That should be more complete than the adaptation layer.
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.
Ok, true...
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.
WEll no, we aren't redesigning 4944. We could provide comments
on it though, it's an RFC, and it's used as basis for LoWPAN ND which is
further used by ROLL.
If RFC 4944 had a multicast-capable adaptation layer, or required
802.15.4 to offer such, then probably the ER wouldn't be required to do
the otherwise unnecessary proxying.
In LoWPAN ND the ER proxies ND on its egress interface, on behalf of
each LoWPAN nodes, i.e. sending an MLD Report for each node. Hundreds
of thousands of such reports - why? It would be simpler if ER separated
the links and had two multicast-capable links.
---------------
|Upstream Router|
---------------
|
|Egress
---
|ER |
---
|
0 0
0 0 0 (nodes)
Edge routers are introduced to scale the Neighbor Discovery
Operations by reducing the amount of costly multicast ND messages
over a LoWPAN subnet that may cover hundreds or thousands of nodes.
At the cost of what? Moving the problem from LoWPAN to ER's Egress
interface - why?
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
