Hi Alex,
Alexandru Petrescu wrote:
Greg Daley wrote:
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.
I don't even think manual configuration should be done on those devices.
They can't do the ND component properly, regardless of the Router Discovery component.
NS uses multicast as well, and is the basis of DAD.
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.
Not plain broadcast, plain multicast.
broadcast shouldn't be used because it prevents any attempts at MAC filtering, not because filtering is required.
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.
I'll reply to this below.
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.
Hang on a minute:
ND uses multicast on:
Neighbour Solicitation (Solicited-Nodes:All Address Resolution, DAD)
Neighbour Advertisement (All-Nodes : only really on becoming a Proxy ND,
and DAD completion)
Router Solicitation (All-Routers: Always)
Router Advertisemen: (All-Nodes: when multicast delivery is usedOnly one of these is (almost) guaranteed to be on the fixed network infrastructure side of the network (RA).
So, in every other case they are mutlicast. This means that in your
plan, every IPv6 host sends NS's, RS's and Unsolicited NA's out every LAN segment and cell?
And still the nodes can'd handle MLD (v1 or v2) queries...
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.
No-one uses hubs anymore. This is the 21st century.
Clearly I'm generalizing, but we shouldn't build in bad technology for the sake of a few devices.
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.
It's not as simple as that.
Now we've got a deployed base. What do we do about 2460/2461/2462/2463 compliant nodes?
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
