Sign in with
Sign up | Sign in
Your question

Filtering of multicast MAC source address?

Last response: in Networking
Share
Anonymous
May 13, 2004 2:19:10 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi,

My initial thought would be that if a bridge receives a frame with a
source address consisting of a a group or broadcast address, it should
be discarded as it is clearly erroneous.

However, I cannot find anything in 802.1D supporting this.
Source address is clearly defined as the address of the device from
which the frame originated, but it is never mentioned what to do with
such errors.

The section discussing the learning process states that one of the
criteria for a source address being added to the Filtering Database is
that it is NOT a group address.

Also there is a note stating tha learning is based on source
addresses, and filtering is based on destination addresses.

So, I am no longer sure about how to treat frames with group source
addresses (or broadcasts).
It seems like they should be let through.

Am I missing something here?
Are there any "unwritten rule" that states these frames should be
discarded?
...or are there any good reason they should not?

Thanks
Geir
Anonymous
May 13, 2004 6:26:01 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Geir" <news@neverwhere.ws> wrote:

> Hi,
>
> My initial thought would be that if a bridge receives a frame with a
> source address consisting of a a group or broadcast address, it should
> be discarded as it is clearly erroneous.

This is correct.

> However, I cannot find anything in 802.1D supporting this.

Reading standards is tricky business. IEEE 802.1D says in Clause 7.5:

"NOTE-A frame that is in error, as defined by the relevant MAC
specification, is discarded by the MAC Entity without giving rise to any
M_UNITDATA indication; see 6.4."

So this tells us to look at the specific MAC spec, which I assume in
your case would be IEEE 802.3. Which states explicitly:

"2.3.1.2 Semantics of the service primitive

[ ... ]
The destination_address parameter may specify either an individual or a
group MAC entity address. It must contain sufficient information to
create the DA field that is prepended to the frame by the local MAC
sublayer entity and any physical information. The source_address
parameter, if present, must specify an individual MAC address."

Bert
Anonymous
May 13, 2004 8:54:15 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Geir <news@neverwhere.ws> wrote:
> Hi,

> My initial thought would be that if a bridge receives a frame with a
> source address consisting of a a group or broadcast address, it should
> be discarded as it is clearly erroneous.

> However, I cannot find anything in 802.1D supporting this.
> Source address is clearly defined as the address of the device from
> which the frame originated, but it is never mentioned what to do with
> such errors.

> The section discussing the learning process states that one of the
> criteria for a source address being added to the Filtering Database is
> that it is NOT a group address.

> Also there is a note stating tha learning is based on source
> addresses, and filtering is based on destination addresses.

> So, I am no longer sure about how to treat frames with group source
> addresses (or broadcasts).
> It seems like they should be let through.

> Am I missing something here?

Multicasting is a IP-level thing. rfc1112 section 6.2 says :
The IP source address of the outgoing datagram must be one of the
individual addresses corresponding to the outgoing interface.

A host group address must never be placed in the source address field
or anywhere in a source route or record route option of an outgoing
IP datagram.



> Are there any "unwritten rule" that states these frames should be
> discarded?
> ..or are there any good reason they should not?

bridges does not deal with multicast, the _might_deal with
"group-addresses (which is a simular thing on level-2 ). Multicast
datagrams are normally transported via group-adress mechanisms
on a ieee80x media, thus they are somewhat interdependent.

Sending frames with a group-address as source seems very wrong, one
reason is that it's not possible to reply. nother reason is
that it might fool a "non-groupaddress-aware" bridge into
beliving that a certain group-address exists at a certain port,
thus preventing packets destined to this group-address to reach
other destinations. ( as noone should use group-addresses as
source they are "unknown" to all bridges, thus flooded to
all interfaces).




> Thanks
> Geir

--
Peter HÃ¥kanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
Related resources
Anonymous
May 14, 2004 12:09:46 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

On Thu, 13 May 2004 14:26:01 GMT, "Albert Manfredi"
<albert.e.manfredi@nospam.com> wrote:


>Reading standards is tricky business. IEEE 802.1D says in Clause 7.5:
>
>"NOTE-A frame that is in error, as defined by the relevant MAC
>specification, is discarded by the MAC Entity without giving rise to any
>M_UNITDATA indication; see 6.4."

Yes, this was what I was looking for.
Getting all the details in the first ten readings is tricky indeed :-)

Thanks
Geir
Anonymous
May 22, 2004 3:52:20 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Albert Manfredi" <albert.e.manfredi@nospam.com> wrote in message news:<HxnpFD.I6A@news.boeing.com>...

> "NOTE-A frame that is in error, as defined by the relevant MAC
> specification, is discarded by the MAC Entity without giving rise to any
> M_UNITDATA indication; see 6.4."
>
> So this tells us to look at the specific MAC spec, which I assume in
> your case would be IEEE 802.3. Which states explicitly:
>
> "2.3.1.2 Semantics of the service primitive
>
> [ ... ]
> The destination_address parameter may specify either an individual or a
> group MAC entity address. It must contain sufficient information to
> create the DA field that is prepended to the frame by the local MAC
> sublayer entity and any physical information. The source_address
> parameter, if present, must specify an individual MAC address."

And the reason that this is explicitly called out as a MAC-specific
thing is probably because Token Ring uses the multicast bit of the
source MAC address as the RII (routing information indicator) to indicate
that the frame is a source routed frame and that the source routing header
follows the source MAC address. Of course, source routed bridges have
no need to do learning.

Anoop
!