Filtering of multicast MAC source address?

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
4 answers Last reply
More about filtering multicast source address
  1. 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
  2. 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.
  3. 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
  4. 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
Ask a new question

Read More

Ethernet Card Macintosh Networking