Subject: (IPng 6780) RE: Problem with "smart" layer 2 switches

From: Brian Zill <[email-masked]>
Date: Tue, 24 Nov 1998 21:29:57 -0800

Well, it now looks like I got worried without cause.  Thanks everyone for
your comments.  The problem we observed is now believed to be a physical
hardware problem with a particular switch.  A replacement switch is working
just fine with IPv6 even when its "IGMPv4 snooping" feature is enabled.

As Francis points out, it's o.k. for a switch to do this IGMPv4 snooping
trick so long as it only blocks multicast addresses in the range allocated
to IPv4.  The piece of information I had been missing was that the ethernet
multicast address space is large enough to have distinct regions for v4 vs.
v6 multicast (which it does).  So my worry, which Tim also expressed in his
followup, had been that the solicited node multicast address space would be
too large to easily filter (or rather, NOT filter).  The broken hardware we
had was exhibiting the behavior of filtering ALL multicast addresses outside
of the v4 ones it was explicitly allowing, which as Matt points out, would
break a lot of other stuff besides IPv6 (but I suspect we don't run a whole
lot of AppleTalk around here :-)

So I retract my warning that I know of a vendor shipping a layer 2 switch
with a feature that causes the switch to only work with IPv4.  This isn't to
say they aren't out there, but my existence proof went away.

--Brian

-----Original Message-----
From: Brian Zill [mailto:[email-masked]]
Sent: Wednesday, November 18, 1998 21:59
To: [email-masked]
Subject: (IPng 6762) Problem with "smart" layer 2 switches

This is a FYI about a problem we ran into recently that I thought might
interest others on this list.  It's likely to pose a problem with some IPv6
deployments.

Our facilities folks just put in a "smart" 10/100 BaseT ethernet switch to
service our building.  It has a feature that's intended to reduce
unnecessary multicast traffic on the individual segments.  When this feature
is enabled, it doesn't propagate packets for ethernet multicast addresses to
all ports on the switch.  Instead, it snoops all the incoming ports for IGMP
(v4) join messages and only then enables multicast traffic for the port it
saw the join on (and even then I believe it only enables traffic to that
specific multicast address).

Needless to say, this breaks Neighbor Discovery for IPv6.  We had a
representative from the switch vendor onsite yesterday (an engineer, not a
sales/marketing guy), and this was the first he had ever heard of IPv6's
multicast requirements.  I explained the issue to him, so at least one
vendor of such devices is now aware of it.  Fortunately, this feature can be
disabled on our switch.

In talking with our facilities people, I got the impression that these sort
of IPv4 centric features are becoming more common on layer 2 switches.  So
this is one more potential problem to look for when deploying v6.  I suppose
it could even be a barrier to deployment in environments where the local
network manager has become attached to this sort of feature.

--Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------