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

From: Brian Zill <[email-masked]>
Date: Wed, 18 Nov 1998 21:58:56 -0800

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 19 Nov 1998 10:32:41 +0100

In your previous mail you wrote:

   
=> it is a correct behavior (we asked for it two years ago) but
of course only for 1:0:5e:xx:yy:zz with xx < 80 only.

   multicast requirements.

=> perhaps it was the first time he has ever heard of something else
than IPv4 on Ethernet...

   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.
   
=> you (we?) should explain that IGMP spoofing is a good (smart :-) feature
but it must be correctly implemented. Do we need an information RFC
about it ?

=> there are new versions of IGMP in the pipe and perhaps MLD spoofing
will be nice then this issue is important...

Thanks

[email-masked]

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 19 Nov 1998 08:42:45 -0600

If the "smart" switch filters multicast packets which aren't IP(v4),
it's already broken, with or without IPv6 present on the network.
Think of Appletalk, DECNET, and all the other protocols which do
multicasts.
				Matt Crawford
   "We break more code before 8 AM than most people write all day."
--------------------------------------------------------------------
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]
--------------------------------------------------------------------