Does a NIC 'know' its MAC address?

Question

My understanding is that an Ethernet NIC 'knows' its MAC address. When packets arrive on the wire, the NIC checks to see if the destination MAC matches its MAC, and if so, forwards the packet up the network stack. This alleviates the operating system of having to examine each and every packet that arrives on the wire.

I'd like to know which OS driver functions support this. I've been looking at the NDIS 5.1 reference, and have found this: http://msdn.microsoft.com/en-us/library/windows/hardware/ff557131%28v=vs.85%29.aspx and I think I'm close, but haven't hit the jackpot yet.

I'm preparing class materials and I want to tell my class that the NIC knows its MAC address, but don't want to teach that unless I can verify to myself that it's true. Seeing the OS driver functions that support this would satisfy my doubt.

I appreciate any help (and comment) the community could provide.

Answer 1

Drivers are the wrong place to look for this information, since addressing is (generally) handled by the card before the driver even gets involved. Check the wikipedia article on MAC addresses:

MAC addresses are most often assigned by the manufacturer of a network interface controller (NIC) and are stored in its hardware, such as the card's read-only memory or some other firmware mechanism. If assigned by the manufacturer, a MAC address usually encodes the manufacturer's registered identification number and may be referred to as the burned-in address (BIA).

Drivers might support fetching the NIC's address, and in some cases changing it (overriding the factory-defined address), but for the most part drivers will just leave the MAC layer up to the NIC.

Answer 2

Packet filtering

Your understanding is correct. A NIC does a fair amount of filtering in hardware, to spare the CPU from excessive filtering. Generally, a typical Ethernet NIC will have a programmable packet filter that only allows packets if they meet certain criteria, like these:

• The destination MAC address matches one of a set of programmable destination addresses (typically you'd put your own unicast address into the target set, as well as several multicast addresses).
• The destination address is the broadcast address (for Ethernet, that's ff-ff-ff-ff-ff-ff).
• The destination address is any multicast address (for Ethernet, the first byte has its LSB set)

In typical operation, Windows will program a NIC to accept traffic destined to the NIC's unicast address, the broadcast address, and a handful of multicast address (e.g., for IPv6 Neighbor Discovery and UPnP).

The hardware packet filter's only purpose is to reduce CPU usage of the host. Windows does not rely on the hardware packet filter for functional correctness. If a badly-behaved NIC were to always indicate all packets unfiltered, Windows would automatically fall back to filtering in software.

Updating the packet filter

Windows may modify the packet filter on the hardware. For example, if you run Netmon or Wireshark and enable their "Promiscuous mode", NDIS will instruct the NIC to indicate all traffic, even if the destination is a non-local unicast address.

If you would like an interesting lab experiment, open up PowerShell and run this command to query the current packet filter:

Get-WmiObject -Namespace root\wmi -Class MSNdis_CurrentPacketFilter |
    Format-List InstanceName, NdisCurrentPacketFilter

You can pipe that to another command to make the output more readable:

    % { @{ $_.InstanceName = "{0:X8}" -f $_.NdisCurrentPacketFilter } }

The packet filter is presented as an integer, which a bitmask of the NDIS_PACKET_TYPE_XXX constants from the SDK/WDK header file ntddndis.h. Now if you enable promiscuous mode in Netmon or Wireshark, you should see the packet filter change to include the NDIS_PACKET_TYPE_PROMISCUOUS flag (0x20). Disabling Netmon or Wireshark will restore the pre-existing packet filter.

Other filtering types

I've just described the most basic level of packet filtering, which nearly all Ethernet NICs support. (Microsoft requires this minimal level of support with the "Device.Network.LAN.Base.PacketFiltering" logo requirement.) More sophisticated hardware can do cool stuff.

For example, hardware that supports multiple receive queues has multiple receive filters. The NIC indicates the packets that match each filter separately, on separate CPUs, to make it easier for a hypervisor to distribute traffic to virtualized guest operating systems.

Disclaimer

Your question mentions both OS X and NDIS, a Windows technology. My remarks only apply to NDIS and Windows, as I work for Microsoft.