Martin Dunmore wrote:
<snip>
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.
So the obvious question is... how do we know if a receiver on the link cannot use 33 multicast? I dont know of a way for the IP stack to find this out.
Right. The problem is I don't know about about a way for the IP stack to find out that the receiver _does_ use 33 multicast. It simply assumes it. The RFC assumes it.
But assuming that we can and do detect such a reciever then all multicast RA/ND messages from a router would then have to use ff broadcast?
No no, only the RA and NA messages that are intended to be broadcasted, and broadcasted to the complete set of members, not just some group address derived from a specific MAC address.
For example, RAs can be sent to either 33:33::1 or to specific MAC addresses too. Those that can be sent to 33:33::1 should be able to be sent to all-ff too. It's just a change in notation. There is no change in scalability or power consumption.
Perhaps it would be simpler just to add some text saying that Ethernet NICs that do not support 33 multicast may not (cannot?) be able to support v6?
"cannot" is too strict. IPv6 is a big thing. Only a certain form of easy stateless autoconf is not supported if the 33 multicast is not supported. If a non-33 host sends a RS to a pre-configured router then that host does receive a directed RA.
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 --------------------------------------------------------------------
