MAC Address Lookup Explained: Format, OUI, and Address Bits

This guide covers: MAC Address Lookup Explained: Format, OUI, and Address Bits.

Most people who type "MAC address lookup" into a search bar are looking for the wrong answer. A MAC address will tell you which chipset is probably in a device, whether the address is randomized, whether the frame is unicast or multicast, and which port a switch learned it on. It will not tell you where someone lives, who owns the laptop, or which website they just visited. Treat the MAC as the most useful identifier inside one network segment, and the least useful one the moment traffic leaves the building. The whole point of this article is to make that distinction sharp enough that you stop wasting time on it.

What a MAC address actually is

Strictly: a 48-bit identifier defined by IEEE 802 standards, assigned to a network interface, used at OSI layer 2 to deliver frames inside a broadcast domain. That definition matters because it tells you what the address is for, which is forwarding decisions on the local segment. Routers strip the layer-2 header and write a new one when they forward your packet onto the next link. The IP address survives that hop; the MAC address does not.

The notation everyone uses is six pairs of hex characters: 00:1A:2B:3C:4D:5E. Same value, different separators in different tools. There is also a 64-bit variant, EUI-64, which exists almost entirely so IPv6 stateless autoconfiguration can derive an interface identifier from a MAC. We will get to it. Most of the addresses you will ever see are EUI-48.

The reason this matters before any lookup work is scope. A MAC address is meaningful at one switch, one Wi-Fi access point, one VLAN. Past the first router, what comes out the other side has a different source MAC because the router rewrote it. So when somebody asks whether they can "trace" a MAC across the internet, the answer is genuinely no. Not in some lawyerly hedge way. The address does not survive routing.

Why MAC lookups still earn their keep

Inside the segment, though, MAC addresses are gold. Switch CAM tables index by MAC. Wi-Fi access points authenticate and account by MAC. ARP and IPv6 neighbor discovery resolve IP-to-MAC mappings constantly. DHCP servers hand out leases keyed to MAC. Wireshark color-codes by OUI. Network access control systems use MAB (MAC Authentication Bypass) for devices that cannot do 802.1X. If you spend any time with packet captures, switch logs, or wireless controllers, MAC addresses are everywhere and you need to read them quickly.

A useful MAC lookup workflow does five things, in order: normalize the format, classify the address (unicast vs. multicast, universal vs. local), look up the OUI, sanity-check the result against context (what kind of device should be on this port?), and pivot to other layers if the answer needs more than the MAC alone can give. The rest of this article is the long version of those five steps.

The four formats you will see in the wild

• IEEE colon format: 00:1A:2B:3C:4D:5E — Linux, BSD, macOS, Wireshark, RFC examples.
• IEEE hyphen format: 00-1A-2B-3C-4D-5E — Windows ipconfig and most Microsoft tooling.
• Cisco dotted format: 001A.2B3C.4D5E — Cisco IOS, NX-OS, and several routing vendors.
• Bare hex: 001A2B3C4D5E — vendor APIs, some switch exports, and the format you most often have to clean up before processing.

Always normalize before comparing. Two log lines that look different often refer to the same address. The cheapest way to do it is to strip every non-hex character, uppercase the result, and re-insert separators in whatever style the rest of your pipeline expects. Five lines of code; saves hours of false negatives.

OUI, MA-L, MA-M, MA-S: the assignment hierarchy

The IEEE Registration Authority sells address blocks. The traditional block, an OUI proper, is 24 bits and gives the buyer 16,777,216 addresses to assign. That is what people mean when they say "the first three octets identify the vendor." The price of a public OUI assignment as of recent years has been on the order of $3,000, with discounts for keeping the assignee's identity private rather than published in the public registry.

Smaller blocks exist. MA-M is a 28-bit prefix giving 1,048,576 addresses; MA-S is a 36-bit prefix giving 4,096 addresses. Both are cheaper. The practical implication for anyone running a lookup is that you cannot trust the first 24 bits alone to identify the vendor when a MA-M or MA-S block is in play. The remaining 4 or 12 bits are part of the prefix, not part of the device portion. A naive lookup table that only knows about 24-bit OUIs will report the block-holder of the 24-bit prefix, which may be a rental company or an aggregator, not the actual buyer of the smaller block.

Good lookup data sources handle all three sizes. The IEEE publishes the registries as CSV files. Wireshark's manuf file is essentially a curated, regularly updated version of the same thing. If you are building tooling, use one of those rather than a scraped fragment from a third-party site.

Bit-level structure of the first octet

Two bits in the first octet carry meaning that is independent of any vendor lookup. Memorize them once and you will read MAC addresses forever after.

• I/G bit (least significant bit of the first octet, mask 0x01). Zero means individual (unicast); one means group (multicast). When you see a destination MAC starting with an odd first byte, it is multicast or broadcast. Source MACs are always unicast and therefore always have an even first byte.
• U/L bit (second-least-significant bit, mask 0x02). Zero means universally administered (assigned by the manufacturer out of an IEEE block); one means locally administered (made up by the device or operating system, randomized, virtualized, spoofed).

Combine those and you get a fast classification table for the first byte:

• Bits 0 and 0: universal unicast — the "real" manufacturer MAC. 00:, 04:, 08:, etc.
• Bits 1 and 0: universal multicast — vendor-defined multicast groups. 01:, 05:, 09:.
• Bits 0 and 1: locally administered unicast — randomized, spoofed, or VM-generated. 02:, 06:, 0A:,0E:, 12:, 16:, and so on.
• Bits 1 and 1: locally administered multicast — rare in practice but legal. 03:, 07:, 0B:.

Practical consequence: if you spot a packet capture full of source MACs starting 02:, 06:, 0A:, or 0E:, you are almost certainly looking at randomized Wi-Fi clients. No OUI lookup will tell you anything about them, and that is by design.

The multicast and broadcast MACs worth knowing on sight

• FF:FF:FF:FF:FF:FF — the broadcast address. Every device on the segment receives the frame. ARP requests and DHCP discoveries use it.
• 01:00:5E:xx:xx:xx— IPv4 multicast. Only 23 of the IPv4 group's 28 bits map into the MAC, which means 32 different IPv4 multicast groups collide onto each MAC; modern hardware filters at the IP level to compensate.
• 33:33:xx:xx:xx:xx — IPv6 multicast. Lower 32 bits of the IPv6 group address map directly. Neighbor discovery solicitations and router advertisements ride on these.
• 01:80:C2:00:00:00 through 01:80:C2:00:00:0F — the IEEE 802.1D Bridge Group Address range. STP, LLDP, LACP, and a long list of bridge-control protocols sit here. Most switches treat these as link-local and never forward them past one hop.
• 01:00:0C:CC:CC:CC — Cisco Discovery Protocol (CDP).01:00:0C:CC:CC:CD — Cisco PVST. If you see these on a link that is supposed to be vendor-neutral, somebody plugged in a Cisco device.

EUI-64 and the IPv6 privacy story

IPv6 stateless address autoconfiguration originally derived the lower 64 bits of an interface address from the MAC. The conversion: split the 48-bit MAC in half, insert FF:FE in the middle, and flip the U/L bit. So 00:1A:2B:3C:4D:5E would become 02:1A:2B:FF:FE:3C:4D:5E, and the resulting IPv6 address would carry that interface identifier.

Which means, for a few years in the early IPv6 deployment story, your Wi-Fi MAC was leaking out into every IPv6 address you used on the public internet. Every server you connected to could correlate your sessions across networks by reading the lower half of the address. The privacy implications were obvious, and RFC 4941 (later refreshed as RFC 8981) introduced privacy extensions: a random interface identifier, rotated periodically, with no MAC bits embedded.

Every modern operating system uses privacy extensions by default for outbound connections. Windows, macOS, iOS, Android, and major Linux distributions all ship with the relevant settings on. There are still cases where the EUI-64 form leaks — manually configured servers, embedded devices that never got the patch, certain VPN clients with bad defaults — and those are worth checking with our IPv6 leak test tool whenever you are evaluating a network for privacy hygiene.

The Wi-Fi MAC randomization revolution

Around 2014, retailers and analytics companies started building passive Wi-Fi tracking systems. A device with Wi-Fi turned on and not connected sends out probe requests advertising its MAC address. Anyone with a directional antenna and a logging laptop could collect those probes and, over time, reconstruct shopper traffic patterns by device. The London "smart bins" story in 2013, the Nordstrom Wi-Fi tracking pilot, and several similar efforts produced enough public backlash that operating systems took notice.

The fix rolled out in stages:

• iOS 8 (2014) introduced randomized MACs in probe requests when not associated with a network. iOS 14 in 2020 extended randomization to associated networks, with a different random MAC per SSID, persisting per network.
• Android 10 (2019) made per-SSID randomization the default; Android 12 added the option to randomize per connection rather than per network.
• Windows 10 (2015) shipped per-network and per-day randomization options. Windows 11 kept the same model with cleaner UI.
• macOS Sonoma (2023) brought iOS-style per-SSID randomization to the Mac. Earlier macOS versions used randomized probes but a stable associated MAC.

The practical effect on lookup work is that you cannot trust the OUI of a Wi-Fi client MAC anymore unless you have a reason to believe the device is older, embedded, or has randomization disabled. Smart-home devices and industrial gear often still expose real MACs, which is partly why those device classes still get reliably profiled by network discovery tools and randomized phones do not.

Recognizing a randomized MAC at a glance

Three quick checks. First, the locally-administered bit: if the second bit of the first byte is set (the byte ends with 2, 6, A, Ein hex when the high nibble is even), it is locally administered. Almost all randomized Wi-Fi MACs have this set. Second, the OUI lookup result: if the first 24 bits return "Private" or "Locally Administered" or fail to find a vendor, it is randomized. Third, behavior: a real device's MAC tends to be stable across sessions on the same SSID; a randomized MAC may change after factory reset, OS update, or per-connection rotation depending on platform settings.

If you are running a captive portal, an enterprise wireless controller, or a guest network with a paid-time policy, MAC randomization is the single biggest reason your old assumptions broke. The fix is usually to authenticate at the user or session level rather than the device level, or to require a device to opt out of randomization for that SSID. Modern enterprise wireless platforms ship UI for both.

Real commands for collecting and inspecting MACs

On Windows, the canonical starting points:

getmac /v
ipconfig /all
arp -a
Get-NetAdapter | Format-Table Name, MacAddress, Status, LinkSpeed

On Linux:

ip link show
ip -br link
ip neigh show
ethtool -P eth0
arp -an

On macOS:

ifconfig
networksetup -listallhardwareports
arp -an
ndp -an   # IPv6 neighbor cache

For a packet capture filtered to a specific source MAC in tcpdump: tcpdump -i en0 ether src 00:1a:2b:3c:4d:5e. In Wireshark, the equivalent display filter is eth.src == 00:1a:2b:3c:4d:5e. Wireshark's manuf-resolution feature substitutes the OUI portion with the vendor name, which is why you often see addresses like Apple_3c:4d:5e in the packet list — that is the same address with the OUI translated.

Switch CAM tables, the real MAC database

On Cisco IOS, the canonical command is show mac address-table. Add address 00:1a:2b:3c:4d:5e to narrow to one entry. The output tells you VLAN, address, type (dynamic or static), and the port the switch learned it on. That last piece — the port — is what lets you walk a network back from a MAC to a physical jack on the wall, which is the most common operational reason to do MAC lookup at all.

Cisco MAC entries age out at 300 seconds by default. If a device has been silent for that long, the entry disappears until the next frame from it arrives. That is normal; it is also why intermittently-connected devices vanish from show mac address-table output even though they are still plugged in. Adjust aging time on a per-VLAN basis if you have a good reason; most networks should not.

Juniper's equivalent is show ethernet-switching table; Arista uses show mac address-table like Cisco. HPE ProCurve and Aruba CX have their own variants that all return the same conceptual data. Once you have the port, you can pivot to show interface, show lldp neighbors, or a cabling map to find the physical endpoint.

ARP, neighbor discovery, and the cache that bites you

ARP (for IPv4) and Neighbor Discovery (for IPv6) maintain the IP-to-MAC mapping for every active local-segment peer. The cache lives on every host, not just on switches. When something is unreachable on the LAN, the cache is the first place to look: a stale or wrong entry causes traffic to go to the wrong MAC, and from the user's perspective the symptom is "timeouts for no reason."

Common operations:

# Linux: clear the ARP cache for one entry
sudo ip neigh del 192.168.1.10 dev eth0

# macOS: same idea
sudo arp -d 192.168.1.10

# Windows: flush all
netsh interface ip delete arpcache

ARP cache poisoning is also where the security side of MAC analysis starts. An attacker on the segment can spoof gratuitous ARP responses claiming the gateway's IP belongs to their own MAC, and inhale every host's traffic. The countermeasures are Dynamic ARP Inspection on managed switches, static ARP entries on critical hosts, and segment-level isolation so that the attack surface stays small. None of those involve a MAC lookup tool, but spotting an unexpected MAC suddenly answering for a known IP is what triggers the investigation in the first place.

DHCP reservations, broken by randomization

DHCP servers traditionally identified clients by MAC. The router UI offers "reserve this IP for this MAC," and you do that for printers, NAS boxes, and anything that needs a stable address. Randomization broke this for phones and laptops because each new SSID gets a different MAC, and the reservation no longer matches. The result was a wave of confused users wondering why their home network suddenly stopped giving the laptop its usual address after a factory reset.

Two paths forward. For devices that genuinely need a stable address, turn off MAC randomization for that SSID — most operating systems expose it as a per-network setting. For better long-term identification, DHCPv6 uses a DUID (DHCP Unique Identifier) that does not change with MAC rotation. Modern routers increasingly support DUID-based reservations on the IPv6 side. The IPv4 story is messier because DUID was never standardized for DHCPv4.

MAC spoofing: when it is fine and when it is not

Changing your MAC is a one-line command on every modern OS. The technique is sometimes called spoofing, but the term covers everything from legitimate troubleshooting to clearly malicious impersonation.

# Linux
sudo ip link set dev eth0 down
sudo ip link set dev eth0 address 02:11:22:33:44:55
sudo ip link set dev eth0 up

# macOS
sudo ifconfig en0 ether 02:11:22:33:44:55

# macchanger on Linux for a random one
sudo macchanger -r eth0

Legitimate uses include resetting a stuck captive portal that has already burned the daily allowance of free Wi-Fi minutes for your original MAC, replacing a failed router and not wanting to wait for the upstream ISP's DHCP lease to expire on the old MAC, and cloning the documented MAC of a piece of equipment whose firmware cannot accept a new value. Less legitimate uses include bypassing MAC-based network access control or impersonating someone else's authorized device. The technical bar is the same; the legal context is not.

For lookup purposes, the takeaway is that a real MAC and a spoofed one look identical on the wire. The only ways to tell them apart are out-of-band: cross-checking with switch port history, with 802.1X EAP authentication logs, or with whatever endpoint inventory the device should be matched against.

Where MAC lookup actually pays off

• Asset inventory triage. Forty unknown MACs in a DHCP lease list reduce to ten unknowns once you OUI-resolve them and remove the obvious printers, smart TVs, and network gear.
• Wireshark walkthroughs. Vendor name in the source column lets you spot the management station and the mystery device at a glance instead of memorizing OUIs.
• Wireless controller dashboards. Identifying which devices are Apple, Samsung, or Cisco helps when you are tuning a network for specific client behavior — Apple devices in particular have idiosyncrasies that affect roaming and DFS.
• Switch port mapping. Walk the path from a known MAC, through the CAM table, to a port, to a patch panel jack. That is the actual day-job version of network forensics.
• NAC and MAB bypass detection. If a port is configured for MAC Authentication Bypass with a specific OUI range and a frame appears with an unrelated OUI, that is a hard signal worth investigating.
• Security event correlation. When the SIEM reports a suspicious flow, the source MAC in the local logs maps to one device. Without that step, the same incident is harder to pin to a person or asset.

What MAC lookup cannot do, plainly

• It cannot identify a person or address. A MAC is a hardware identifier, not a contact record.
• It cannot survive routing. A MAC seen on the LAN is not the same MAC the next hop sees, because every router rewrites the layer-2 header.
• It cannot reliably identify the manufacturer of a randomized device. The whole point of randomization is to prevent that.
• It cannot replace IP geolocation, ASN, WHOIS, or reverse DNS. Different layers of the stack, different questions answered.
• It cannot prove the device's authenticity in an untrusted network. Anyone can spoof a MAC; you need 802.1X with certificates or out-of-band attestation for that.

Why OUI databases lie more often than you think

Three categories of common error. First, vendor consolidation: an OUI registered to a company that was acquired ten years ago still appears in lookup tables under the old name. Cisco, Hewlett-Packard, and 3Com between them have absorbed dozens of smaller networking vendors, and the OUI history is messy. Second, chip-supplier OUIs: many low-cost devices use Realtek, Mediatek, or Broadcom Wi-Fi chipsets, and the device's MAC reflects the chipset manufacturer rather than the brand on the box. A Realtek OUI on a USB Wi-Fi dongle could mean any of fifty different brands. Third, block reassignments: the IEEE has reassigned defunct OUIs in some cases, so historical and current data may differ.

Practical mitigation: use the IEEE registry directly when accuracy matters, treat OUI as a hypothesis rather than a fact, and triangulate with other signals — DHCP hostname, mDNS service announcements, HTTP user agents from logs — before drawing conclusions about which physical device a MAC represents.

Bluetooth and the same problem in a different domain

Bluetooth Device Addresses (BD_ADDRs) are also 48 bits and use a very similar IEEE OUI scheme. The privacy story is similar too: early Bluetooth devices broadcast a public address, which retailers and stalkers could log. Modern Bluetooth (especially Bluetooth Low Energy) supports Random Static, Resolvable Private, and Non-Resolvable Private addresses, and the device negotiates which one to use with each peer. AirDrop, AirTag detection, and most modern proximity features rely on resolvable private addresses that rotate frequently. If you are doing Bluetooth-side lookup, the same caveats about randomization apply, with even more aggressive rotation.

Building a small but reliable lookup database

For anyone running their own MAC analysis tooling, the practical question is where to source data. The IEEE publishes three CSVs: oui.csv for traditional 24-bit assignments, mam.csv for 28-bit medium blocks, and oui36.csv for 36-bit small blocks. Pull all three. Combine them into a single trie indexed by prefix length, longest match wins. That gives you correct lookups for every block size, and it is the structure most professional tools use internally.

Refresh the data on a schedule — monthly is plenty. New OUI assignments happen weekly; the bulk of devices in real networks were manufactured against assignments that have been stable for years, so the urgency is low. What matters more is keeping the dataset complete: scraped fragments from third-party sites tend to miss the smaller blocks and the most recent additions, and you will get wrong answers at the edges.

For supplementary data, the Wireshark manuffile bundles cleaned-up vendor names and short-form aliases that are nicer to display than the IEEE registry's legal-names format. It updates with every Wireshark release and can be redistributed. Combining the IEEE registry for accuracy with the Wireshark file for presentation gives you the best of both.

The historical context worth remembering

From roughly 2010 to 2015, Wi-Fi MAC tracking became a small industry. Renew London ran "recycling bins" that logged passing devices in 2013; the city told them to stop after the press coverage. Nordstrom briefly piloted a similar in-store system the same year. Several airports, malls, and stadiums used the same approach to measure foot traffic and dwell time.

The OS-vendor response was MAC randomization, and it largely worked. But the same fingerprinting goal moved up the stack — to advertising IDs, browser fingerprints, and Bluetooth beacons. Knowing that history is useful when you are evaluating a new tracking technique: the surface changed, the underlying business model did not, and the countermeasures are always one version of the OS behind the advertisers.

A realistic diagnostic walkthrough

Imagine the scenario: a user reports that a specific laptop will not connect to the office Wi-Fi, but works fine on Ethernet. The wireless controller logs are empty for the laptop's expected MAC. Here is how the workflow runs in practice.

1. Get the laptop's actual Wi-Fi MAC. Run getmac /v on Windows or ifconfig en0 on macOS, identifying the wireless interface specifically. Compare with what is on file. If the live MAC differs from the documented one, the OS is randomizing per SSID and the device record is stale. That is the first finding in roughly half of these cases.
2. Check the controller for the new MAC. If it shows up associated but stuck in a captive-portal state, the issue is RADIUS or NAC policy not having a record for this address. If it does not show up at all, the problem is earlier — radio, driver, or the SSID configuration.
3. Look at probe requests from the device. Most enterprise wireless platforms expose a separate "rogue clients" or "probing devices" view. The laptop should be probing for the SSID. If it is not, the supplicant on the host is broken or the radio is hard-disabled.
4. If the device is probing and being rejected, drop a packet capture on the AP's monitor interface for that band. The authentication exchange tells you whether the issue is at WPA handshake (key mismatch, certificate trust), at 802.1X EAP (RADIUS reachability, supplicant config), or after authentication (DHCP failing, VLAN misassigned).
5. Resolve. Either turn off MAC randomization on the laptop for that SSID and update the NAC record, or update the policy to accept the new locally-administered MAC pattern, or fix whichever earlier step actually failed.

The reason this workflow works is that it pivots between layer-2 identity (MAC), authentication identity (RADIUS/EAP), and layer-3 addressing (DHCP) in the right order. Skipping the MAC step is the most common reason troubleshooters chase the wrong problem for an hour. A two-second check of the actual current MAC against the documented one rules out half the possibilities before any deeper investigation.

802.1X, WPA-Enterprise, and why MAC matters less in good networks

On a well-built corporate network, MAC addresses are not an access control mechanism. They are inventory. Authentication runs through 802.1X with EAP-TLS or PEAP, the device proves identity with a certificate, and the MAC is just the layer-2 address that gets used for forwarding once the session is established. On those networks, MAC randomization is largely fine: every device authenticates as itself regardless of which random MAC it presents.

The networks where MAC still matters for access are the ones that cannot do better — printers, IoT, unmanaged guest networks, devices that lack 802.1X support entirely. For those, MAC Authentication Bypass (MAB) is the fallback: the switch checks the MAC against an allowlist and forwards if it matches. MAB is widely deployed and widely known to be bypassable. If the device on the other end is a printer, the threat model rarely justifies stronger authentication. If it is something more sensitive, MAB should be paired with port-level controls (Dynamic ARP Inspection, DHCP Snooping, BPDU Guard) and ideally migrated to 802.1X-capable hardware over time.

For Wi-Fi specifically, WPA3-Enterprise with Suite-B and certificate authentication is the current best practice. It removes MAC from the access decision entirely and uses cryptographic identity instead. Networks running this configuration are immune to the entire class of MAC-spoofing problems that older WEP and WPA2-PSK deployments struggled with.

Common mistakes when working with MAC data

• Comparing addresses without normalizing first. 00-1A-2B-3C-4D-5E and 001a.2b3c.4d5e are the same address. Strip and compare canonical forms.
• Trusting the OUI on a Wi-Fi client. Modern phones and laptops randomize. The OUI may not exist in any registry, and that is normal.
• Looking for a MAC in public-internet logs. It will not be there. The router stripped it three hops ago.
• Treating MAC reservations as a security control. A spoofed MAC bypasses the reservation just as easily as a real one matches it. Use 802.1X for actual access control.
• Assuming aged-out CAM entries mean the device left. They may just have been silent. Check the wireless controller and the DHCP lease state too.
• Confusing multicast or broadcast with unicast in capture filters. A filter that misses 33:33: or 01:00:5E: ranges drops a lot of useful neighbor-discovery traffic.
• Forgetting that virtual machines and containers generate their own MACs.A locally-administered MAC inside a hypervisor often has nothing to do with the host's NIC.

Useful IP Trackers tools alongside MAC analysis

• MAC Address Lookup handles format normalization, bit interpretation, and OUI/NIC breakdown in one place.
• IP Location Lookup covers what the MAC cannot: geolocation context for the public IP a device uses upstream of the LAN.
• ASN Lookup picks up where MAC analysis ends, mapping public IPs to routing-domain owners.
• Reverse DNS gives IP-derived hostnames that often add real context to a triage flow.
• WHOIS / RDAP Lookup provides ownership data for the IP side that no MAC lookup can surface.
• IPv6 Leak Test confirms whether an EUI-64-style identifier is leaking out of a VPN or system that should be using privacy extensions.

Frequently asked questions

What do the first six hex digits of a MAC mean? Usually the OUI prefix, identifying the IEEE-assigned block. With MA-M and MA-S blocks, the prefix is 28 or 36 bits respectively, so 24 bits alone is not always enough to identify the assignee.

Can a MAC address tell me where a device is located? No. It is a layer-2 identifier. It does not survive routing and does not carry geolocation data on its own. Some Wi-Fi positioning services correlate MACs of access points with locations, but that is the access point's MAC, not the client's, and it depends on a precomputed database.

Can MAC addresses be randomized? Yes. Every modern consumer operating system randomizes the MAC for Wi-Fi by default. The randomized address has the locally-administered bit set and will not match any IEEE OUI registry.

Is MAC lookup useful in Wireshark? Very. The manuf-resolution feature swaps OUI prefixes for vendor names in the UI, and display filters like eth.src and eth.addr let you slice captures by device. Most practical Wireshark work involves MAC-level filtering at some point.

Can a MAC address replace IP investigation? No. They answer different questions. MAC tells you what is on this segment; IP, ASN, WHOIS, and reverse DNS tell you what is on the public internet.

Is a MAC address unique forever? Universally administered MACs are intended to be globally unique. In practice, spoofing, randomization, and locally administered addresses break that assumption all the time. Treat uniqueness as a default expectation, not a guarantee.

How do I tell if a MAC is randomized? Check the second-least-significant bit of the first byte. If the first byte ends in 2, 6, A, or E in hex (when the high nibble is even), it is locally administered. Real device MACs almost always end in 0, 4, 8, or C in that position.

Why does my phone's MAC keep changing? Because per-SSID randomization is the default on iOS and Android. Each new network gets a different MAC. To get a stable address on a specific network, turn off the randomization toggle for that SSID in your phone's Wi-Fi settings.

Does a VPN hide my MAC address? The MAC address is not exposed past the first router with or without a VPN. A VPN protects the IP address from sites you visit, not the MAC, which was never visible to them in the first place.

How do switches use MAC addresses? Each switch learns which port maps to which MAC by inspecting incoming frames, and stores the mapping in its CAM table. When a frame arrives for a known destination MAC, the switch forwards it only to the right port. This is the foundation of Ethernet switching and the reason switches scale far better than the hubs they replaced.

Are MAC addresses still relevant in IPv6? Yes, for layer-2 forwarding the MAC is exactly as important as in IPv4. IPv6 just stopped baking it into the routable address. Neighbor Discovery still maps IPv6 addresses to MACs on the local segment, the same way ARP did for IPv4.

Continue with IP Address Lookup Explained, Public vs Private IP, What Is My ISP?, What Is ASN?, and CIDR Explained.

By Theodore Uzun

Founder and Senior Software Engineer, IP Trackers

Published February 13, 2026Editorially reviewed