I think that Alex was thinking about end hosts which don't support IPv6.
YEs, hosts that support v4 ok and can't support v6 because of the 33 requirement of RA (RAs must be sent to 33:33:0:0:0:1 by this RFC). Receiving an initial RA is essential to configure the stack. Ok, IPv6 stack configuration could be done manually, but in that case using IPv4 is more advantageous than using IPv6 because IPv4 uses DHCP autoconfiguration.
It is intentional though that Routers use multicast for Neighbour Discovery in order to identify packet destinations, rather than rely on flooding.
Good. It's just that routers should not use multicast for ND when multicast is not available and simply use broadcast. It's better to use broadcast and have things working, better than just assuming that multicast works and have nothing working.
Using ff:ff:ff:ff:ff:ff completely defeats this mac-layer filtering (as does 33:33:33:00:00:01, since all ipv6 hosts will use this group)
MAC-layer filtering should be used when available, but the entire IPv6 ND should not rely on its existence. IPv6 ND should work with plain broadcast as well.
The only way to identify the frames to forward (without causing switches to peer into L3 for every frame) is to have smaller groups which will not be bridged out every port.
If we start sending multicast frames as ff:ff:ff:ff:ff:ff, we can say
goodbye to a scalable, long-term IPv6 over BNEP/Bluetooth and even 802.11 in bridged environments.
Hold on, we're not saying goodbye to "scalable". It's good to have "scalable" stuff. But it's also good to have things working instead of not working because of scalability worries. I think in hotspot areas they use all-ff DHCP DISCOVER - ok that's not scalable but that works.
Hosts would _always_ wake up to process ff:ff:ff:ff:ff:ff frames, if they were incorporated in IPv6.
I mean have the "broadcasted" RAs (not the unicasted) sent to all-ff if 33 is not possible. I don't mean to have all ND to use all-ff. First, just have the RA to all-ff if 33 not available. If ok, then maybe the NA too. But only the ND messages that are broadcast in nature.
This wastes battery power for wireless hosts, as well as the previously mentioned bandwidth.
ND messages that are broadcast in nature are sent to everybody under the same hub anyways, it's going to wake everybody up anyways, it's just that the address notation is different.
We've got more multicast than ever in IPv6.
Good.
In that case, there will be old cards which can't support 33:33 MAC addresses. Perhaps it is well to note that these cards won't be able to run IPv6.
Ok, so that's an option. Another is to just say that when 33 multicast is not available for broadcast, just use ff broadcast.
Alex
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
