Subject: RE: about v6 over multicast-less Ethernet

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 28 Feb 2005 15:42:00 -0500

> 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.

Bert

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Greg Daley <[email-masked]>
Date: Tue, 01 Mar 2005 10:21:21 +1100

Hi

Manfredi, Albert E wrote:
> 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