non-unicast source MAC?

Hi,
I have a short question:
In layer 2, is there a chance to receive a packet with a non-unicast
source MAC?

Thanks,
Ali Ayoub

On 19 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) om>, Ali Ayoub wrote:

>I have a short question:

which you posted to the wrong newsgroup. The more appropriate group is

[compton ~]$ grep ethernet big.8.list.03.15.07
comp.dcom.lans.ethernet Discussions of the Ethernet/IEEE 802.3 protocols.
[compton ~]$

>In layer 2, is there a chance to receive a packet with a non-unicast
>source MAC?

There _shouldn't_ be. The DIX specification referenced by RFC0894 has
the following in section 6.2.1.2:

6.2.1.2 Source Address Field

The source address field contains the physical address of the station
sending the frame. This field is not interpreted at the Data Link Layer.
It is specified at the data link layer because a uniform convention for
the placement of this field is crucial for most higher level protocols.

Client layers use the Data Link physical address for the source address
of all frames transmitted.
______^^^

If you think about the purpose of this field, there is no reason for the
data to be anything except the unicast MAC. See also RFC1812 Section 3.3.2.

1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
(Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated by
RFC2644) (Status: PROPOSED STANDARD)

which says

A router MUST not believe any ARP reply that claims that the Link
Layer address of another host or router is a broadcast or multicast
address.

None the less there is a current thread in the comp.protocols.tcp-ip
newsgroup with the subject "ARP reply containing a multicast MAC OK?" where
one respondent reports the microsoft has some brain-damaged idea (as does
Nokia) relating to load sharing. That is violate standards is typical of
microsoft.

Old guy