Hi
Manfredi, Albert E wrote:
Alexandru Petrescu wrote:
Anyone proposed until now to update RFC2464 "IPv6 over Ethernet Networks"? If not, I'd like to propose updating the following text:
An IPv6 packet with a multicast destination address DST,
consisting
of the sixteen octets DST[1] through DST[16], is
transmitted to the
Ethernet multicast address whose first two octets are the
value 3333
hexadecimal and whose last four octets are the last four
octets of
DST.
Not all Ethernet links/cards/drivers/firmware support this 3333 value, nor even Ethernet multicast groups. Those who don't will work fine with v4 (6 times ff) but not with v6. So some relaxing text saying "either 33:33:xx:xx:xx:xx or ff:ff:ff:ff:ff:ff" may help.
I don't understand why ND is so tight to the Ethernet multicast in the first place, but anyways.
Not sure I understand the problem.
For IPv4 multicast, the Ethernet address becomes 01-00-5E and the lowest 23 bits of the IPv4 Class D address.
For IPv6, 33-33 and the lowest 32 bits of the IPv6 multicast address.
Don't all Ethernet cards and drivers understand the meaning of the LSbit of the first byte (the G/I bit)? As long as that bit is set to 1, won't all Ethernet switches know to flood the frame to all ports in the spanning tree?
More exactly, what I meant was won't all Ethernet switches *at least*
> know to flood those frames to all ports in the spanning tree, even > if they don't do anything more intelligent.
I think that Alex was thinking about end hosts which don't support IPv6.
Really, the difference is very important between 33:33:QR:ST:UV:YZ and ff:ff:ff:ff:ff:ff.
Ethernet networks are commonly bridged, and many mechanisms exist (GARP, IGMP/MLD snooping) which attempt to limit the propagation of multicast messages over bridges where the data is not needed.
This is quite different to unicast forwarding, which floods and then prunes with packets coming from a unicast source. It is intentional though that Routers use multicast for Neighbour Discovery in order to identify packet destinations, rather than rely on flooding.
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) 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.
Hosts would _always_ wake up to process ff:ff:ff:ff:ff:ff frames, if they were incorporated in IPv6. This wastes battery power for wireless hosts, as well as the previously mentioned bandwidth.
We've got more multicast than ever in IPv6. let's not turn it into IPX.
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.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
