Subject: Re: about v6 over multicast-less Ethernet

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2005 12:27:09 +0100

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.

Not sure I understand the problem myself either.  It's just that RAs are
sent to 33:33:0:0:0:1 and some cards don't get the packets addressed to
that (but they do get the packets addressed to ff:ff:ff:ff:ff:ff).
Remark all-ff is what DHCPv4 uses.

Whether cards not receiving 33-addressed RAs is a common problem or not
- I don't know, I'm asking.

> For IPv4 multicast, the Ethernet address becomes 01-00-5E and the 
> lowest 23 bits of the IPv4 Class D address.

A certain DHCPv4 implementation uses all-ff for broadcasting.

> For IPv6, 33-33 and the lowest 32 bits of the IPv6 multicast address.
> 
Yes, but what happens when the Ethernet below does not support
multicast?  Where are all the IPv6-multicast-addressed packets sent to
when the Ethernet below does not support multicast?  Shouldn't they be
sent to the broadcast 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?

May be so, I don't know.

Alex

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 1 Mar 2005 07:21:37 -0500

My experience with ethernet cards and drivers is that if they don't
have multicast capability, they map MAC addresses with the group
bit on to FF:FF:FF:FF:FF:FF prior to transmit.

On the receive side, these cards would go into promiscuous receive
mode and then filter at the device driver.

Regards,
Brian

On Mar 1, 2005, at 6:27, Alexandru Petrescu wrote:

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 1 Mar 2005 23:08:57 +1030

Hi Brian,

On Tue, 1 Mar 2005 07:21:37 -0500

> mode and then filter at the device driver.

Are you able to put a rough date of manufacture on those cards/chipsets
? I've recently done a bit of looking into the chips on the old NE2K
style cards (the NatSemi NS8390D chipset), and even they have a
multicast filtering capability. I first encountered them on NICs in 1992
(if not earlier, maybe 1990 or so), so I'm curious how much earlier
before that multicast was implemented the way you have stated.

Thanks,
Mark. 

-- 

    The Internet's nature is peer to peer.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 1 Mar 2005 07:45:00 -0500

Hi Mark,
      Wow, let me see if I can dust off the date.  The cards I am
referring to were circa 1993-1995.  I can't recall coming across
an ethernet chip after 1995 that did not have some level of
multicast filtering ability.  YMMV...

Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2005 13:58:44 +0100

Brian Haberman wrote:

> have multicast capability, they map MAC addresses with the group bit
> on to FF:FF:FF:FF:FF:FF prior to transmit.

Yep but about the transmitter that _does_ have the multicast capability
and the receiver that does not have the multicast capability.

> mode and then filter at the device driver.

Yes but what about cards that can't go into promiscuous receive mode.  I 
understand that promiscuous mode is probably the easiest way for a card 
to do, but from my experience not all cards can do promiscuous mode.

Alex

---

From: Mark Smith <[email-masked]>
Date: Tue, 1 Mar 2005 23:39:47 +1030

Hi Alex,

On Tue, 01 Mar 2005 13:58:44 +0100

> to do, but from my experience not all cards can do promiscuous mode.

Do you have examples of such hardware / chipsets ? I'd think it'd have
to be really, really old not to have basic multicast and promiscous
capabilities. I'd wonder about the value of introducing layer 2
broadcasts into IPv6 just to cater for such old and rare hardware.

Regards,
Mark.

--

---

From: Brian Haberman <[email-masked]>
Date: Tue, 1 Mar 2005 08:14:46 -0500

I am not sure what to do in order to deal with such an interoperability
issue.  The IPv6 layer has no way of knowing what the capabilities
are of the other NICs on a LAN.

Do you have a proposal to address such issues?

Regards,
Brian

On Mar 1, 2005, at 7:58, Alexandru Petrescu wrote:

> Yes but what about cards that can't go into promiscuous receive mode.  
> I understand that promiscuous mode is probably the easiest way for a 
> card to do, but from my experience not all cards can do promiscuous 
> mode.
>
> Alex
>

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 01 Mar 2005 08:12:52 -0500

> before that multicast was implemented the way you have stated.

I think it's far more likely that Alexandru is running into broken
drivers and/or bridges.

I've seen: 
 1) device driver bugs.  either they fail to program the multicast filter
or they try and get it wrong.  A common multicast filter is a bit vector with
associated hash function.   (if filter[hash(dst)] is set, receive packet).  If the driver miscomputes the hash function, bits don't move. 

Many ethernet chipsets have a "receive all multicasts" bit, which at least
saves you from the full pain of promiscuous mode.

 2) firmware bugs in 802.11 access points.  (the vendor had a firmware
upgrade available fixing it by the time I noticed the problem).

						- Bill

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Mar 2005 15:51:34 +0200

>broadcasts into IPv6 just to cater for such old and rare hardware.
I tend to agree. We need a reality check here. If the problem
is with Ethernet cards from '92 then there is no point in worrying
about this. People who care about new stuff already use newer
hardware, or will get new hardware if they run into a problem. In
fact, if you use stuff from '92 I wouldn't be surprised if you had
lots of other problems too, like lack of drivers for modern OSes,
incompatibility with current physical bus and interface connections,
etc.

On the other hand, if the problem is in bad drivers (as Bill points
out), this may be a different issue. I guess part of the problem is
that for plain old IPv4 usage multicast features in NICs and the
drivers don't get tested well, so you see problems  when you
switch to IPv6 or other things that depend on multicast capabilities.
Is there any way to  determine how widespread this problem is?
Personally,  I have never seen it.  But YMMV.

--Jari

---

From: Mark Smith <[email-masked]>
Date: Wed, 2 Mar 2005 00:32:15 +1030

On Tue, 01 Mar 2005 15:51:34 +0200

> incompatibility with current physical bus and interface connections,

(Heh, my mate's old 80486DX66 with 20MB of RAM that he lent me runs the
latest Linux kernels with a 1992 WD8013 ethernet NIC, and it's running
IPv6 fine :-) )

> Personally,  I have never seen it.  But YMMV.

As Martin Dunmore suggested -

"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?"

might be a good way to cover this situation. I'd think it would also
provide an incentive for bad drivers to be fixed. 

Regards,
Mark.

--

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2005 15:07:02 +0100

Bill Sommerfeld wrote:
>> Are you able to put a rough date of manufacture on those 
>> cards/chipsets ? I've recently done a bit of looking into the chips
>>  on the old NE2K style cards (the NatSemi NS8390D chipset), and 
>> even they have a multicast filtering capability. I first 
>> encountered them on NICs in 1992 (if not earlier, maybe 1990 or 
>> so), so I'm curious how much earlier before that multicast was 
>> implemented the way you have stated.
> 

Yes, I'm running into a card that does not implement multicast for the
"broadcast" packets and does not plan to either in the near future.  It
doesn't "promiscuous" either.  So I'm only left with the option of the
router sending RAs to all-ff instead of to 4-3s.  Which I did, but which
is non-standard by this RFC.

> I've seen: 1) device driver bugs.  either they fail to program the 
> multicast filter or they try and get it wrong.  A common multicast 
> filter is a bit vector with associated hash function.   (if 
> filter[hash(dst)] is set, receive packet).  If the driver miscomputes
>  the hash function, bits don't move.

Thanks.  It's not the case here.  The current code simply says /*TODO*/.

> Many ethernet chipsets have a "receive all multicasts" bit, which at
>  least saves you from the full pain of promiscuous mode.

Oh?  I have to check that.

>  upgrade available fixing it by the time I noticed the problem).

Ok, that's an option, I'll have to wait and see.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2005 15:11:19 +0100

Mark Smith wrote:
> Do you have examples of such hardware / chipsets ? I'd think it'd
> have to be really, really old not to have basic multicast and
> promiscous capabilities. I'd wonder about the value of introducing
> layer 2 broadcasts into IPv6 just to cater for such old and rare
> hardware.

Yeah, I think it seems to be a unique local example which makes it
exceptional, so maybe don't bother with the RFCs.

It's just that it's something I can't fix in the host driver so I fix it
in the router's driver, and the overall is non-RFC.

If other people haven't run into this problem maybe it's not worth
dealing with it in the RFC.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2005 15:24:38 +0100

Brian Haberman wrote:
> I am not sure what to do in order to deal with such an 
> interoperability issue.  The IPv6 layer has no way of knowing what 
> the capabilities are of the other NICs on a LAN.

Exactly, that's why I find this difficult.

> Do you have a proposal to address such issues?

An idea is to write in the RFC that "broadcasted" RAs can be sent to
either the 33-like address (33:33::1) or to the all-ff address or to
both, depending on a three-value configuration knob.

But I think I'll have to wait and see whether anybody else has this
problem, then wait for a firmware upgrade and then I'll see whether a
proposal may solve this issue.  In the mean time I'll use non-standard
router to send the "broadcasted" (no directed) RAs to the all-ff
address.  That fits me.

Alex

---

From: David Malone <[email-masked]>
Date: Tue, 1 Mar 2005 14:48:10 +0000

> Is there any way to  determine how widespread this problem is?

I've seen this problem once or twice on FreeBSD, where the driver
author either didn't have enough information to program the multicast
filters or didn't complete the programming of the multicast filters
because it wasn't necessary for the normal opperation of IPv4. Mind
you, all such problems that I knew about have been fixed for some.

(The practical version of the promiscuous mode work-around for this
problem is to run "tcpdump -i blah" in the background on a problem
machine.)

I've seen a few other reasons that multicast ethernet frames have
been dropped. I've seen an IGMP snooping that only understands IPv4,
but turning off IGMP snooping fixed that. One type of VLAN tagging
on some old Cisco switches didn't seem to pass multicast traffic
properly (switching to 802.1q fixed that). I've heard reports of
802.11 APs that don't behave, but never seen one myself.

	David.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2005 17:17:08 +0100

David Malone wrote:

>>  out), this may be a different issue. I guess part of the problem
>> is that for plain old IPv4 usage multicast features in NICs and the
>> switch to IPv6 or other things that depend on multicast
>> capabilities. Is there any way to  determine how widespread this
>> problem is?
> 
> 

I presume promisc and tcpdump is used on a wide scale to avoid this
problem.  I for myself have used it very often on various wifi cards
Orinoco and Cisco.

For one, I don't think this is a proper way to assume that IPv6 works ok
over these cards.  This [promisc] is something one can do in the lab on
some computer where one can type commands, or on cards that do support
this promisc.  For two, putting the card in promisc mode and then saying
that multicast is beneficial because it offers scalability, less
processing power etc - is little appropriate.

Anyways, please do not get me wrong.  It is not in my intentions  to
heat any discussion or whatever.  I just have a local problem whose only
solution was to send RAs to ff.  Things may change with driver updates
and so on.

Alex

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 01 Mar 2005 11:43:50 -0500

> Thanks.  It's not the case here.  The current code simply says /*TODO*/.

That suggests to me that the hardware is capable but the driver author is busy.

> Ok, that's an option, I'll have to wait and see.

using ethernet broadcast for your own private testing seems perfectly 
reasonable as a hackaround to let you exercise the rest of the system, but 
asking for everyone else to implement that hackaround in their v6 stack 
before you've exhausted your options with your vendor seems like going about
things in the wrong order..

> Personally,  I have never seen it.  But YMMV.

I've seen it a few times.  I've actually also seen something far more horrific: 
an RTOS network driver interface which (a) pushed ethertype filtering into
the driver, and (b) did not allow any way for the stack to request specific
ethertypes.  If it wasn't ETHERTYPE_ARP or ETHERTYPE_IP, it went straight into
the bit bucket.  No V6 for you!

I've seen no evidence the problem is hardware. 

					- Bill

---

From: Bob Hinden <[email-masked]>
Date: Tue, 01 Mar 2005 11:28:24 -0800

Mark,

>that do not support 33 multicast may not (cannot?) be able to support v6?"

Doesn't this also mean that these NICs don't completely support IEEE 
Ethernet either?  I haven't looked in a while, but I thought that Ethernet 
multicast was part of the base Ethernet specification.

Bob

---

From: Mark Smith <[email-masked]>
Date: Wed, 2 Mar 2005 09:45:15 +1030

Hi Bob,

On Tue, 01 Mar 2005 11:28:24 -0800

> multicast was part of the base Ethernet specification.

I've just briefly looked at the 2002 revision of 802.3, and multicast /
group-addresses is definately described in it. It doesn't seem to
mention it is optional, although I haven't really done any work with
IEEE specs to know if there is some list in them somewhere consisting of
required and optional compliance features. The 1500 pages if the 802.3
spec is quite a lot to read :-)

Regards,
Mark.

(As a side note, just in case people don't know, you can now download
fairly recent PDF revisions of quite a number of the 802 specs for free
from http://www.ieee802.org, as long as you don't redistribute them.)

--