Hubbry Logo
MAC addressMAC addressMain
Open search
MAC address
Community hub
MAC address
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
MAC address
MAC address
MAC address
View on Wikipedia
from Wikipedia
Label of a UMTS router with MAC addresses for LAN and WLAN modules

A MAC address (medium access control address or media access control address) is a unique identifier assigned to a network interface controller (NIC) for use as a network address in communications within a network segment. This use is common in most IEEE 802 networking technologies, including Ethernet, Wi-Fi, and Bluetooth. Within the Open Systems Interconnection (OSI) network model, MAC addresses are used in the medium access control protocol sublayer of the data link layer. As typically represented, MAC addresses are recognizable as six groups of two hexadecimal digits, separated by hyphens, colons, or without a separator.

MAC addresses are primarily assigned by device manufacturers, and are therefore often referred to as the burned-in address, or as an Ethernet hardware address, hardware address, or physical address. Each address can be stored in the interface hardware, such as its read-only memory, or by a firmware mechanism. Many network interfaces, however, support changing their MAC addresses. The address typically includes a manufacturer's organizationally unique identifier (OUI). MAC addresses are formed according to the principles of two numbering spaces based on extended unique identifiers (EUIs) managed by the Institute of Electrical and Electronics Engineers (IEEE): EUI-48—which replaces the obsolete term MAC-48—and EUI-64.

Network nodes with multiple network interfaces, such as routers and multilayer switches, must have a unique MAC address for each network interface in the same network. However, two network interfaces connected to two different networks can share the same MAC address.

Address details

[edit]
The structure of a 48-bit MAC address. b0 (the least significant bit) of the most significant octet distinguishes multicast and unicast addressing, and b1 of the same octet distinguishes universal and locally administered addressing.

The IEEE 802 MAC address originally comes from the Xerox Network Systems Ethernet addressing scheme.[1] This 48-bit address space contains potentially 248 (over 281 trillion) possible MAC addresses. The IEEE manages the allocation of MAC addresses, originally known as MAC-48 and now called EUI-48 identifiers. The IEEE has a target lifetime of 100 years (until 2080) for applications using EUI-48 space and restricts applications accordingly. The IEEE encourages adoption of the more plentiful EUI-64 for non-Ethernet applications.[2]

The distinctions between EUI-48 and MAC-48 identifiers are in name and application only. MAC-48 was used to address hardware interfaces within existing 802-based networking applications; EUI-48 is now used for 802-based networking and is also used to identify other devices and software, for example Bluetooth.[3][4] The IEEE now considers MAC-48 to be an obsolete term.[5] EUI-48 is now used in all cases. In addition, the EUI-64 numbering system originally encompassed both MAC-48 and EUI-48 identifiers by a simple translation mechanism.[3][a] These translations have since been deprecated.[3]

The Individual Address Block (IAB) is an inactive registry which has been replaced by the MA-S (MAC address block, small), previously named OUI-36, and has no overlaps in addresses with the IAB[6] registry product as of January 1, 2014. The IAB uses an OUI from the MA-L (MAC address block, large) registry, previously called the OUI registry. The term OUI is still in use,[6] but the IEEE Registration Authority does not administer them. An OUI is concatenated with 12 additional IEEE-provided bits (for a total of 36 bits), leaving only 12 bits for the organisation owning the IAB to assign to its (up to 4096) individual devices. An IAB is ideal for organizations requiring not more than 4096 unique 48-bit numbers (EUI-48). Unlike an OUI, which allows the assignee to assign values in various number spaces (for example, EUI-48, EUI-64, and the various context-dependent identifier number spaces, as in SNAP or EDID), the Individual Address Block could only be used to assign EUI-48 identifiers. All other potential uses based on the OUI from which the IABs are allocated are reserved and remain the property of the IEEE Registration Authority. Between 2007 and September 2012, the OUI value 00:50:C2 was used for IAB assignments. After September 2012, the value 40:D8:55 was used. Owners of an already assigned IAB may continue to use it.[7]

The MA-S registry includes, for each registrant, both a 36-bit unique number used in some standards and a block of EUI-48 and EUI-64 identifiers (while the registrant of an IAB cannot assign an EUI-64). MA-S does not include assignment of an OUI.

Additionally, the MA-M (MAC address block, medium) provides both 220 EUI-48 identifiers and 236 EUI-64 identifiers, the first 28 bits being assigned by IEEE. The first 24 bits of the assigned MA-M block are an OUI assigned to IEEE that will not be reassigned, so the MA-M does not include assignment of an OUI.

Universal vs. local (U/L bit)

[edit]

Addresses can either be universally administered addresses (UAA) or locally administered addresses (LAA). A universally administered address is uniquely assigned to a device by its manufacturer. The first three octets (in transmission order) identify the organization that issued the identifier and are known as the organizationally unique identifier (OUI).[3] The remainder of the address (three octets in EUI-48 or five in EUI-64) are assigned by that organization in nearly any manner they please, subject to the constraint of uniqueness. A locally administered address is assigned to a device by software or a network administrator, overriding the burned-in address of a physical device.

Locally administered addresses are distinguished from universally administered addresses by setting (assigning the value of 1 to) the second-least-significant bit of the first octet of the address. This bit is also referred to as the U/L bit, short for Universal/Local, which identifies how the address is administered.[8][self-published source?][9]: 20  If the bit is 0, the address is universally administered, which is why this bit is 0 in all UAAs. If it is 1, the address is locally administered. In the example address 06-00-00-00-00-00, the first octet is 06 (hexadecimal), the binary form of which is 00000110, where the second-least-significant bit is 1. Therefore, it is a locally administered address.[10] Even though many hypervisors manage dynamic MAC addresses within their own OUI, often it is useful to create an entire unique MAC within the LAA range.[11]

Universal addresses that are administered locally

[edit]

In virtualisation, hypervisors such as QEMU and Xen have their own OUIs. Each new virtual machine is started with a MAC address set by assigning the last three bytes to be unique on the local network. While this is local administration of MAC addresses, it is not an LAA in the IEEE sense.

A historical example of this hybrid situation is the DECnet protocol, where the universal MAC address (with Digital Equipment Corporation's OUI AA-00-04) is administered locally. The DECnet software sets the last three bytes of the complete MAC address to 00-XX-YY (so that the full MAC address is AA-00-04-00-XX-YY), where XX-YY reflects the host's DECnet network address xx.yy. This eliminates the need for DECnet to have an address resolution protocol since the MAC address of any DECnet host can be determined from its DECnet address.

Unicast vs. multicast (I/G bit)

[edit]

The least significant bit of an address's first octet is referred to as the I/G, or Individual/Group, bit.[8][self-published source?][9]: 20  When this bit is 0 (zero), the frame is meant to reach only one receiving network interface.[12] This type of transmission is called unicast. A unicast frame is transmitted to all nodes within the collision domain. In a modern wired setting (i.e. with switches, not simple hubs) the collision domain usually is the length of the Ethernet cabling between two network interfaces. In a wireless setting, the collision domain is all receivers that can detect a given wireless signal. If a switch does not know which port leads to a given MAC address, the switch will forward a unicast frame to all of its ports (except the originating port), an action known as unicast flood.[13][self-published source?] Only the node with the matching hardware MAC address will (normally) accept the frame; network interfaces with non-matching MAC-addresses ignore the frame unless they are in promiscuous mode.

If the least significant bit of the first octet is set to 1 (i.e. the second hexadecimal digit is odd) the frame will still be sent only once; however, network interface controllers will choose to accept or ignore it based on criteria other than the matching of their individual MAC addresses: for example, based on a configurable list of accepted multicast MAC addresses. This is called multicast addressing.

The IEEE has built in several special address types to allow more than one network interface card to be addressed at one time:

  • Packets sent to the broadcast address, all one bits, are received by all stations on a local area network. In hexadecimal the broadcast address would be FF:FF:FF:FF:FF:FF. A broadcast frame is flooded and is forwarded to and accepted by all other nodes.
  • Packets sent to a multicast address are received by all stations on a LAN that have been configured to receive packets sent to that address.
  • Functional addresses identify one or more Token Ring NICs that provide a particular service, defined in IEEE 802.5.

These are all examples of group addresses, as opposed to individual addresses; the least significant bit of the first octet of a MAC address distinguishes individual addresses from group addresses. That bit is set to 0 in individual addresses and set to 1 in group addresses. Group addresses, like individual addresses, can be universally administered or locally administered.

Ranges of group and locally administered addresses

[edit]

The U/L and I/G bits are handled independently, and there are instances of all four possibilities.[10] IPv6 multicast uses locally administered, multicast MAC addresses in the range 33-33-XX-XX-XX-XX (with both bits set).[14]: §2.3.1 

Given the locations of the U/L and I/G bits, they can be discerned in a single digit in common MAC address notation as shown in the following table:

Universal/local and individual/group bits in MAC addresses
U/L
I/G
 Universally administered Locally administered
Unicast (individual) X0-XX-XX-XX-XX-XX
X4-XX-XX-XX-XX-XX
X8-XX-XX-XX-XX-XX
XC-XX-XX-XX-XX-XX 		X2-XX-XX-XX-XX-XX
X6-XX-XX-XX-XX-XX
XA-XX-XX-XX-XX-XX
XE-XX-XX-XX-XX-XX
Multicast (group) X1-XX-XX-XX-XX-XX
X5-XX-XX-XX-XX-XX
X9-XX-XX-XX-XX-XX
XD-XX-XX-XX-XX-XX 		X3-XX-XX-XX-XX-XX
X7-XX-XX-XX-XX-XX
XB-XX-XX-XX-XX-XX
XF-XX-XX-XX-XX-XX

IEEE 802c local MAC address usage

[edit]

IEEE standard 802c[15] further divides the locally administered MAC address block into four quadrants. This additional partitioning is called Structured Local Address Plan (SLAP) and its usage is optional.

SLAP quadrants for unicast local MAC addresses
MAC address Quadrant name Identifier Usage
XA-XX-XX-XX-XX-XX Extended local ELI Assigned by IEEE, but uses a unique 3-octet company ID (CID) instead of an OUI.
XE-XX-XX-XX-XX-XX Standard assigned SAI For use in the forthcoming IEEE P802.1CQ specification, to be assigned dynamically by the Block Address Registration and Claiming (BARC) protocol.
X2-XX-XX-XX-XX-XX Administratively assigned AAI Can be randomly or arbitrarily assigned to devices.
X6-XX-XX-XX-XX-XX Reserved Reserved Reserved for future use, but may be used similarly to AAI until an IEEE specification utilizes this space.

Applications

[edit]

The following network technologies use the EUI-48 identifier format:

Every device that connects to an IEEE 802 network (such as Ethernet and Wi-Fi) has an EUI-48 address. Common networked consumer devices such as PCs, smartphones and tablet computers use EUI-48 addresses.

EUI-64 identifiers are used in:

  • IEEE 1394 (FireWire)
  • InfiniBand
  • IPv6 (Modified EUI-64 as the least-significant 64 bits of a unicast network address or link-local address when stateless address autoconfiguration is used.)[16] IPv6 uses a modified EUI-64, treats MAC-48 as EUI-48 instead (as it is chosen from the same address pool) and inverts the local bit.[b] This results in extending MAC addresses (such as IEEE 802 MAC address) to modified EUI-64 using only FF-FE (and never FF-FF) and with the local bit inverted.[14]: sec. 2.2.1 
  • Zigbee / 802.15.4 / 6LoWPAN wireless personal-area networks
  • IEEE 11073-20601 (IEEE 11073-20601 compliant medical devices)[17]

Use in hosts

[edit]

On broadcast networks, such as Ethernet, the MAC address is expected to uniquely identify each node on that segment and allows frames to be marked for specific hosts. It thus forms the basis of most of the link layer (OSI layer 2) networking upon which upper-layer protocols rely to produce complex, functioning networks.

Many network interfaces support changing their MAC address. On most Unix-like systems, the command utility ifconfig may be used to remove and add link address aliases. For instance, the active ifconfig directive may be used on NetBSD to specify which of the attached addresses to activate.[18] Hence, various configuration scripts and utilities permit the randomization of the MAC address at the time of booting or before establishing a network connection.

Changing MAC addresses is necessary in network virtualization. In MAC spoofing, this is practiced in exploiting security vulnerabilities of a computer system. Some modern operating systems, such as Apple iOS and Android, especially in mobile devices, are designed to assign a random MAC address to their network interface when scanning for wireless access points to avert tracking systems.[19][20]

In Internet Protocol (IP) networks, the MAC address of an interface corresponding to an IP address may be queried with the Address Resolution Protocol (ARP) for IPv4 and the Neighbor Discovery Protocol (NDP) for IPv6. Thus ARP and NDP relate OSI layer 3 addresses to layer 2 addresses.

Tracking

[edit]

Randomization

[edit]

According to Edward Snowden, the US National Security Agency has a system that tracks the movements of mobile devices in a city by monitoring MAC addresses.[21] To avert this practice, Apple started using random MAC addresses in iOS devices while scanning for networks.[19] Other vendors quickly followed suit. MAC address randomization during scanning was added in Android starting from version 6.0,[20] in Windows 10,[22] and in Linux 3.18.[23] The actual implementations of the MAC address randomization technique vary largely in different devices.[24] Moreover, various flaws and shortcomings in these implementations may allow an attacker to track a device even if its MAC address is changed, for instance its probe requests' other elements,[25][26] or their timing.[27][24] If random MAC addresses are not used, researchers have confirmed that it is possible to link a real identity to a particular wireless MAC address.[28]

Randomized MAC addresses can be identified by the "locally administered" bit described above.[29]

Other information leakage

[edit]

Using wireless access points in SSID-hidden mode (network cloaking), a mobile wireless device may not only disclose its own MAC address when traveling, but even the MAC addresses associated to SSIDs the device has already connected to, if they are configured to send these as part of probe request packets. Alternatives to prevent this include configuring access points to be in either beacon-broadcasting mode or probe-response-with-SSID mode. In these modes, probe requests may be unnecessary or sent in broadcast mode without disclosing the identity of previously known networks.[30]

Anonymization

[edit]
Main article: MAC address anonymization

Notational conventions

[edit]

The standard (IEEE 802) format for printing EUI-48 addresses in human-friendly form is six groups of two hexadecimal digits, separated by hyphens (-) in transmission order (e.g. 01-23-45-67-89-AB). This form is also commonly used for EUI-64 (e.g. 01-23-45-67-89-AB-CD-EF).[3] Other conventions include six groups of two hexadecimal digits separated by colons (:) (e.g. 01:23:45:67:89:AB), and three groups of four hexadecimal digits separated by dots (.) (e.g. 0123.4567.89AB); again in transmission order.[31]

Bit-reversed notation

[edit]

The standard notation, also called canonical format, for MAC addresses is written in transmission order with the least significant bit of each byte transmitted first, and is used in the output of the ifconfig, ip address, and ipconfig commands, for example.

However, since IEEE 802.3 (Ethernet) and IEEE 802.4 (Token Bus) send the bytes (octets) over the wire, left-to-right, with the least significant bit in each byte first, while IEEE 802.5 (Token Ring) and IEEE 802.6 (FDDI) send the bytes over the wire with the most significant bit first, confusion may arise when an address in the latter scenario is represented with bits reversed from the canonical representation. For example, an address in canonical form 12-34-56-78-9A-BC would be transmitted over the wire as bits 01001000 00101100 01101010 00011110 01011001 00111101 in the standard transmission order (least significant bit first). But for Token Ring networks, it would be transmitted as bits 00010010 00110100 01010110 01111000 10011010 10111100 in most-significant-bit–first order. The latter might be incorrectly displayed as 48-2C-6A-1E-59-3D. This is referred to as bit-reversed order, non-canonical form, MSB format, IBM format, or Token Ring format.[32]

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

MAC address

View on Grokipedia
from Grokipedia
A MAC address, formally known as a Media Access Control address, is a unique 48-bit identifier permanently assigned to a (NIC) for communications within a physical at the OSI model's (Layer 2). This hardware-based address enables devices to recognize and exchange frames on local networks such as Ethernet or , distinguishing individual interfaces without relying on higher-layer protocols like IP addresses, which handle across networks. The standard format divides the 48 bits into two 24-bit halves: the first half comprises the (OUI), a code allocated by the IEEE to manufacturers for identifying the vendor of the NIC, while the second half is a unique assigned by that manufacturer to the specific device. Typically represented in hexadecimal notation as six pairs of characters separated by colons or hyphens (e.g., 00:1A:2B:3C:4D:5E), MAC addresses are embedded in during manufacturing and are intended to be globally unique, though software can spoof them for certain applications. Unlike dynamic IP addresses, MAC addresses provide a stable, low-level foundation for protocols that manage contention and frame delivery in shared media environments, underpinning technologies from wired LANs to standards like IEEE 802.11. While extensions exist for larger address spaces (e.g., EUI-64 for ), the 48-bit MAC-48 remains the dominant format, with IEEE overseeing assignments to prevent collisions and support scalability in expanding device ecosystems.

History

Origins and Early Development

The concept of the MAC address emerged from the early design of Ethernet, a technology developed at Xerox's Palo Alto Research Center (PARC) to interconnect computers using for high-speed data sharing. On May 22, 1973, engineer authored an internal memo outlining the potential for such a network, drawing inspiration from the system and emphasizing collision avoidance in shared media access. Collaborating with David Boggs, Metcalfe implemented the first experimental Ethernet system, which successfully transmitted packets between two computers on November 11, 1973, operating at 2.94 Mbps over 1 km of cable. Central to this prototype was a 48-bit hardware addressing scheme for uniquely identifying network interfaces, or "stations," on the bus , enabling frame delivery and supporting the with (CSMA/CD) protocol to manage contention. The choice of 48 bits provided scalability for millions of devices, with the structure allocating the first 24 bits for vendor-specific identifiers and the remainder for unique serial numbers, a division that facilitated global uniqueness without centralized coordination at the time. Early tests connected personal computers, demonstrating reliable packet transmission amid collisions, though initial speeds were limited by the prototype's custom interface boards. Further refinement occurred through iterative prototyping at PARC throughout the 1970s, incorporating error detection via cyclic redundancy checks and evolving the addressing to handle multicast and broadcast frames for efficient group communication. In 1979, Xerox formed the DIX alliance with Digital Equipment Corporation (DEC) and Intel to commercialize the technology, culminating in the Ethernet Specification Version 1.0 released in September 1980, which standardized the 48-bit "physical station address" at 10 Mbps over thick coaxial cable. This version retained the core addressing mechanism from PARC's work, emphasizing burned-in, non-routable identifiers tied to the physical layer for low-level medium access control.

IEEE Standardization

The IEEE 802 Local and Metropolitan Area Networks Standards Committee was formed in February 1980 to develop interoperable standards for and physical layers in LANs and MANs, including the addressing mechanisms that became known as MAC addresses. This effort built upon the 48-bit physical address format from the earlier DIX Ethernet specification (1980) by , , and , adapting it for the MAC sublayer of the reference model. The committee's work emphasized ensuring address uniqueness to support collision-free communication in shared media environments. IEEE Std 802.3, the first standard incorporating the 48-bit address for Ethernet, was approved on June 8, 1983, by the committee. This standard specified 48-bit destination and source addresses within Ethernet frames, transmitted least significant bit first (little-endian octet order), with the first 24 bits reserved for manufacturer-assigned identifiers to guarantee global uniqueness. Subsequent standards, such as IEEE Std 802.11 for wireless LANs (initially published in 1997), extended the same 48-bit MAC format across diverse physical layers while maintaining compatibility. To administer assignments, the IEEE Registration Authority was established as part of the 802 standardization process, allocating 24-bit Organizationally Unique Identifiers (OUIs) to vendors for the first half of MAC addresses. This mechanism, operational from the early 1980s, prevents duplication by requiring vendors to register and incorporate OUIs into devices, with the remaining 24 bits vendor-specific. The IEEE later formalized the 48-bit structure as Extended Unique Identifier-48 (EUI-48) in standards like IEEE Std 802-2001, distinguishing universally administered (globally unique) from locally administered addresses via the second least significant bit of the first octet.

Evolution and Modern Extensions

Following the establishment of 48-bit MAC addresses (EUI-48) in early standards during the 1980s, subsequent developments addressed the need for longer identifiers in emerging protocols. The EUI-64 format emerged in the as an extension mechanism, concatenating a 24-bit (OUI) with a 40-bit extension or deriving it by inserting the fixed value 0xFFFE between the first three and last three octets of an EUI-48 while flipping the second-least significant bit of the first octet to indicate local scope. This format supported applications such as stateless address autoconfiguration (SLAAC), where the interface identifier portion of the could be generated from the MAC address. However, direct mapping from EUI-48 to EUI-64 has been deprecated since the mid-2010s in favor of distinct EUI-64 assignments by the to avoid unintended universal address generation and ensure proper uniqueness. In response to growing device densities and the limitations of universal address spaces in local networks, IEEE Std 802c, approved on August 25, 2017, amended the Overview and to define structured local MAC address pools. This standard designates ranges within the locally administered address space (second bit set to 1) for protocols using Company IDs (CIDs) assigned by the IEEE , enabling multiple independent administrations to manage unique local identifiers without collision risks across bridged domains. It specifies formats for administratively assigned individual (AAI) and group addresses, ensuring compatibility with existing IEEE 802 media while supporting scalability in environments like large-scale IoT deployments. Privacy considerations have driven further extensions since the 2010s, as fixed MAC addresses enable persistent device tracking across networks via probe requests and association frames. To mitigate this, initiated the Randomized and Changing MAC Addresses (RCMAC) in 2016, leading to amendments that standardize temporary randomized addresses for unauthenticated scanning and probing, distinct from the stable interface MAC. Operating systems implemented these practices earlier; for instance, Apple introduced randomized MACs for scans in (released September 17, 2014) and (released September 20, 2016) when not associated with a network. Similar randomization, often rotating per session or network, became default in Android from version 10 (released September 3, 2019), reducing traceability while preserving network functionality through persistent identifiers for active connections. These changes prioritize causal unlinkability in transient interactions over static hardware binding, though they complicate legacy reliant on fixed MACs.

Technical Structure

Format and Composition

A MAC address, designated as an EUI-48 or MAC-48 identifier in IEEE standards, comprises 48 bits organized into six octets. It is conventionally represented in format using 12 characters, divided into six pairs separated by colons or hyphens, such as 00:1A:2B:3C:4D:5E. This notation facilitates readability, with each pair corresponding to one octet. The structure allocates the first three octets (24 bits) to the (OUI), a code assigned by the IEEE to manufacturers for uniquely identifying their devices. The remaining three octets form the manufacturer-assigned portion, ensuring uniqueness within the vendor's product line. Within the first octet, specific bits define address properties: the least significant bit (bit 0, or I/G bit) distinguishes addresses (0) from group or addresses (1), while the second-least significant bit (bit 1, or U/L bit) indicates universally administered addresses (0, globally unique via IEEE) versus locally administered addresses (1, set by network administrators). These flags enable protocols to handle addressing modes appropriately in networks. Variations in representation exist, including dashed separators or no delimiters (e.g., 001A2B3C4D5E), but the IEEE recommends forms for , such as lowercase with colons in certain contexts like YANG data models. The bit ordering follows the standard octet transmission sequence in Ethernet frames, with the first octet sent first.

Organizationally Unique Identifier (OUI)

The is a 24-bit value assigned by the IEEE to uniquely identify an organization, such as a manufacturer or vendor of networking equipment. In the context of 48-bit addresses like MAC-48 or EUI-48, the OUI occupies the initial three octets, forming the prefix that distinguishes the assigning organization from others worldwide. The remaining 24 bits serve as an extension identifier, which the OUI assignee must allocate uniquely to individual devices or interfaces to ensure global address uniqueness. Assignment of an OUI occurs as part of a MAC Address Block Large (MA-L) registration, where organizations apply through the IEEE Registration Authority's online portal. The process requires payment of a one-time of US $3,480 for public listings, plus potential additional costs such as a US $200 fee, with applications typically processed within seven business days. Confidentiality for the assignment incurs an annual renewal of US $4,020. Once assigned, the OUI cannot be altered or reassigned by the holder, and extensions must conform to IEEE rules to avoid duplication, such as reserving specific bit patterns for group addresses or local use. This identifier underpins the hierarchical structure of MAC addresses in networks, enabling vendors to produce billions of unique device identifiers (2^24 per OUI) without overlap. Public OUI listings are maintained by the IEEE for lookup and verification, aiding in device identification and forensic analysis in networking. Extensions of the OUI concept, such as OUI-36 for smaller blocks, allow finer-grained assignments but retain the core 24-bit organizational prefix for compatibility.

Address Bits and Flags

A standard MAC address, also known as a MAC-48 or EUI-48 identifier, comprises 48 bits divided into six octets, with the first octet containing two key flag bits that define the address's scope and type. The least significant bit (bit 0) of this octet is the Individual/Group (I/G) bit: it is set to 0 for addresses targeting a single network interface and to 1 for group addresses, which include addresses delivered to multiple interfaces or the (all bits set to 1) delivered to all interfaces on the local network segment. The second least significant bit (bit 1) is the Universal/Local (U/L) bit, which distinguishes between globally administered addresses and locally administered ones: a value of 0 indicates a universal address assigned by the IEEE through its Registration Authority, ensuring uniqueness across manufacturers, while a 1 denotes a local address configured by network administrators, which may override the manufacturer-assigned identifier but risks collisions if not managed carefully within the local scope. For universal addresses (U/L=0), the upper 24 bits (including bits 2 through 7 of the first octet) form the Organizationally Unique Identifier (OUI), allocated to vendors by the IEEE, with the remaining 24 bits vendor-specific; setting the U/L bit to 1 allows reuse of the OUI space locally without global uniqueness guarantees. These flags enable efficient frame processing in networks: receiving interfaces can quickly filter frames based on the I/G bit before deeper inspection, and the U/L bit supports flexible address management in scenarios like or privacy-enhanced , where devices periodically change local MAC addresses to mitigate tracking. The combination of these bits reserves specific address spaces—for instance, universal unicast addresses occupy the quadrant where both bits are 0—while prohibiting certain patterns, such as universal group addresses with I/G=1 and U/L=0 in standard assignments to avoid conflicts with protocols.

Variations in Length and Form

The primary lengths for Extended Unique Identifiers (EUIs) used as MAC addresses are 48 bits for EUI-48 (also known as MAC-48) and 64 bits for EUI-64, as specified by the IEEE for unique network interface identification across its 802 standards family. EUI-48 consists of 6 octets (48 bits total), typically represented in hexadecimal as six pairs of digits separated by colons (e.g., 00:1A:2B:3C:4D:5E), providing a total of approximately 2^48 unique identifiers, with the first 24 bits allocated as the (OUI) and the remaining 24 bits for manufacturer-specific extensions. EUI-64 extends to 8 octets (64 bits), represented similarly in hexadecimal but with eight pairs (e.g., 02-1A-2B-FF-FE-3C-4D-5E), designed to support larger-scale networks and protocols requiring more identifiers, such as certain IEEE 802 wireless and personal area network standards beyond traditional Ethernet. This format often incorporates a 24-bit OUI followed by a 40-bit extension or, in derivation from EUI-48, inserts the fixed sequence FF:FE between the OUI-derived and device-specific portions while flipping the universal/local bit for compatibility with IPv6 interface identifiers per RFC 4291. IEEE recommends EUI-64 for new designs needing globally unique addresses to future-proof against exhaustion of the 48-bit space, though EUI-48 remains dominant in wired Ethernet (IEEE 802.3) deployments. Less common forms include EUI-60 (60 bits), allocated for specific high-capacity applications, but these are not widely adopted as standard MAC addresses in most networking protocols. Variations in form also encompass bit-level flags: the second-least significant bit of the first octet indicates (0, IEEE-assigned) versus local (1, administrator-assigned) administration, while the least significant bit distinguishes individual addresses (0) from group/ addresses (1), applicable to both lengths for ensuring uniqueness and scope in layer-2 communications. Transmission may use non-canonical bit ordering in some media (e.g., ), but canonical order (least significant bit first within each octet) is standard for representation and assignment.

Assignment and Administration

Global Assignment by IEEE

The IEEE Standards Association's administers the global assignment of MAC addresses, ensuring their uniqueness across worldwide networks through the allocation of address blocks to manufacturers and organizations. These assignments follow standards, where the first 24 bits of a 48-bit MAC address form the (OUI), uniquely identifying the assignee, while the remaining 24 bits are controlled by the assignee for device-specific identification. The process requires applicants to submit detailed applications specifying intended use, after which the Authority reviews and assigns identifiers from available pools, prohibiting applicant-specified values to maintain impartiality. Assignments are categorized by size to accommodate varying needs: MA-L for large blocks providing a full OUI with up to 2^24 individual EUI-48 addresses; MA-M for medium blocks offering subsets of addresses; and MA-S utilizing a 36-bit OUI-36 for smaller allocations, all usable as MAC, , or Ethernet addresses. Globally unique addresses are distinguished by the universal/local (U/L) bit set to 0 in the second least significant bit of the first octet, contrasting with locally administered addresses (U/L=1) managed independently. The public registry at the IEEE site lists assigned OUIs, enabling verification of vendor ownership and preventing duplication. This centralized mechanism, rooted in IEEE 802's framework since its inception in the early 1980s, mitigates address exhaustion by enforcing structured allocation and reserving ranges for special uses, such as (I/G bit=1). Assignees must adhere to guidelines on address usage, including extensions for group addresses, to preserve the integrity of the global namespace. Updates to assignment information require formal requests, ensuring ongoing accuracy in the registry.

Local and Group Address Management

Locally administered MAC addresses are distinguished from universally administered ones by the universal/local (U/L) bit, the second-least-significant bit in the first octet, which is set to 1 to indicate local assignment rather than global uniqueness enforced by the IEEE. These addresses are configured by network administrators or device software to override manufacturer-assigned (burned-in) addresses, commonly for virtual machines, containerized environments, or bridging multiple interfaces while maintaining local network compatibility. Unlike globally unique addresses, local ones require no registration with the and are intended for scope-limited uniqueness within a single administrative domain, such as a LAN segment, to avoid address collisions in that context. Management of locally administered addresses emphasizes administrative responsibility for ensuring uniqueness and avoiding interference with global assignments, as duplication within a broadcast domain can lead to frame delivery failures or loops. The IEEE Std 802c-2017 amendment introduces the Structured Local Address Plan (SLAP), an optional framework partitioning the local address space into quadrants based on the initial octets (e.g., starting with 02-80-... for CID-based local or x2-xx-xx for semantically opaque local), enabling multiple local administrators to coexist without overlap by adhering to defined ranges and protocols for assignment. Protocols like DHCPv6 extensions in RFC 8948 support SLAP by allowing clients or relays to request preferred quadrants, facilitating automated or semi-automated local assignment while preserving collision avoidance. Administrators must verify configurations, such as through tools overriding NIC settings, and monitor for conflicts, particularly in environments with dynamic virtualization where multiple virtual interfaces share a host. Group MAC addresses, identified by the individual/group (I/G) bit—the least-significant bit in the first octet set to 1—designate multicast or broadcast frames for delivery to multiple recipients rather than a single unicast endpoint. Broadcast addresses, fixed as all-1s (FF:FF:FF:FF:FF:FF), flood frames to all stations in the broadcast domain, while multicast addresses (e.g., 01-00-5E-... for IPv4 mapping) target protocol-defined groups, with the IEEE reserving ranges like 01-80-C2-00-00-0x for spanning tree and other control protocols. Management involves protocol-specific allocation: for IP multicast, the lower 23 bits of the MAC derive from the IP address's lower 23 bits after mapping (dropping the first 4 bits of the IP), supporting up to 32 IP groups per MAC to conserve address space. In practice, group address management relies on network devices like switches implementing or MLD for to prune unnecessary floods, reducing bandwidth waste, while local administrators configure filters or VLANs to scope multicast domains and prevent leakage across segments. The IEEE maintains reserved group ranges to avoid conflicts with or local spaces, ensuring protocols like Ethernet bridging treat them distinctly for forwarding decisions. Both local and group addresses underscore the layered administration in networks, where global uniqueness yields to flexible, context-aware assignment under local control, provided implementers follow bit conventions and scope rules to maintain reliable Layer 2 operations.

Reserved Ranges and Special Cases

The first octet of a MAC address contains two significant bits: the individual/group (I/G) bit, which is the least significant bit (0 for /individual addresses, 1 for group//broadcast addresses), and the universal/local (U/L) bit, the second least significant bit (0 for universally administered addresses assigned by the IEEE , 1 for locally administered addresses managed by local network administrators without global uniqueness guarantees). These bits enable differentiation between address types, with universally administered addresses ensuring no duplication across manufacturers and locally administered ones allowing flexibility for virtual machines, temporary assignments, or testing while risking local collisions if not coordinated. The all-ones address (FF-FF-FF-FF-FF-FF) serves as the , a group address to which all devices on a respond, commonly used for protocols like ARP requests. The all-zeros address (00-00-00-00-00-00) is generally reserved and invalid for transmission as a destination in Ethernet , though it may appear as a source in specific contexts like unspecified interfaces or simulations, but it does not correspond to a valid hardware identifier. IEEE reserves specific multicast ranges within the group for standards-defined protocols, particularly the block 01-80-C2-00-00-00 to 01-80-C2-00-00-0F, which bridges do not forward to prevent unnecessary propagation of control traffic. Within this, addresses like 01-80-C2-00-00-00 designate the Bridge Group for and management protocols, while 01-80-C2-00-00-01 to 01-80-C2-00-00-04 handle MAC control and slow protocols. Additional standard group addresses from 01-80-C2-00-00-10 onward support functions like provider bridge operations (e.g., 01-80-C2-00-00-08) and multiple registration (01-80-C2-00-00-0D), assigned permanently to standards or affiliates like ISO/IEC for . These reservations prioritize scarce resources for essential Layer 2 control, ensuring bridges filter them appropriately to maintain network efficiency.
AddressAssignee/StandardPurpose
01-80-C2-00-00-00/X/AE/AXBridge Group address (not forwarded by bridges)
01-80-C2-00-00-01MAC-specific control protocols
01-80-C2-00-00-02/AXSlow Protocols Multicast
01-80-C2-00-00-08Provider Bridge group
09-00-2B-00-00-04ISO 9542All End System Network Entities
Protocol-specific mappings constitute further special cases: IPv4 multicast addresses (224.0.0.0/4) map to the IEEE-assigned range 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF, where the OUI 01-00-5E is dedicated to IANA, and the remaining 23 bits derive from the IP address's low-order bits, accepting a 1:32 collision ratio due to bit truncation. multicast, particularly link-local (ff02::/16) and solicited-node addresses, uses the locally administered range 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF, with the last 32 bits mirroring the address's final 32 bits for efficient neighbor discovery without global assignment. These mappings, while not universally administered OUIs, are standardized to avoid conflicts in mixed environments, though local administrators must avoid overlapping with custom group addresses.

IEEE 802c Local Usage Guidelines

IEEE Std 802c-2017, published on August 25, 2017, establishes guidelines for the usage of locally administered 48-bit MAC addresses to enable structured assignment and coexistence of multiple address assignment protocols within local networks. These addresses, identified by setting the universal/local (U/L) bit to 1 in the first octet (resulting in second digits of 2, 6, A, or E), form the locally administered space, which constitutes half of the total 48-bit MAC address pool. The standard introduces the Structured Local Address Plan (SLAP), an optional framework that subdivides this space into four quadrants based on two specific bits (Y and Z), facilitating disjoint address pools to prevent collisions among protocols from different administrations, such as standards, IETF protocols, or local network managers. SLAP designates the quadrants by the value of the second digit of the MAC address, ensuring that protocols can select ranges aligned with their assignment authority while maintaining global compatibility.
QuadrantSecond Hex DigitBinary (Y Z)Identifier TypeUsage DescriptionAvailable Bits for Identifier
002 (0010)00AAI (Administratively Assigned Identifier)Arbitrary assignment by local network administrators; protocols must ensure uniqueness within the LAN scope.44 bits (~1.8 × 10¹³ addresses)
106 (0110)10ReservedIntended for future administrative use similar to AAI, but with potential reservations for specific protocols; currently available for local assignment with caution to avoid conflicts.44 bits
01A (1010)01ELI (Extended Local Identifier)Assigned using a 24-bit Company ID (CID) from the , providing ~16.8 million addresses per CID for protocols requiring structured local uniqueness.24 bits (CID) + 20 bits (extension)
11E (1110)11SAI (Standard Assigned Identifier)Reserved exclusively for protocols defined in standards, enabling large-scale assignments (up to 44 bits) without external coordination.44 bits (~1.8 × 10¹³ addresses)
Key guidelines emphasize ensuring address uniqueness within the operational domain: address assignment protocols must allocate from disjoint subspaces when multiple schemes coexist on the same LAN, such as avoiding overlap between AAI and SAI ranges. For ELI, organizations obtain CIDs from the IEEE , analogous to OUIs for global addresses, to support vendor-specific local protocols. SAI usage is restricted to IEEE 802-defined mechanisms, with ongoing work like IEEE P802.1CQ specifying protocols for SAI assignment. Administrations employing AAI or the quadrant bear responsibility for collision avoidance, often through local scoping or techniques compliant with the standard. These provisions accommodate legacy uses (e.g., IETF or protocols) while promoting scalable, conflict-free local addressing in diverse network environments.

Applications in Networking

Role in Layer 2 Communications

Media Access Control (MAC) addresses function at the (Layer 2) of the , serving as hardware identifiers for network interfaces to enable direct communication between devices on the same local . In this layer, divided into the MAC sublayer for and addressing, and the Logical Link Control (LLC) sublayer for flow and error management, MAC addresses facilitate frame-level addressing without reliance on higher-layer protocols like IP. They are 48 bits long in standard Ethernet implementations, with the first 24 bits typically allocated as the (OUI) by the IEEE, ensuring global uniqueness for individual addresses while supporting local or group variants. In Ethernet frame transmission, the source MAC address identifies the sending device, while the destination MAC address specifies the recipient, allowing Layer 2 devices such as switches to process and forward frames based solely on local topology. Switches maintain a dynamic MAC address table (also known as a forwarding database), learned by inspecting the source MAC address of incoming frames and associating it with the ingress port; upon receiving a frame, the switch examines the destination MAC to determine the egress port, forwarding unicast frames only to that port or flooding to all ports in the same VLAN if the destination is unknown or a broadcast/multicast address. This mechanism reduces unnecessary traffic compared to hubs, which broadcast all frames, by enabling selective forwarding that confines communication to the local broadcast domain. MAC addresses delimit the scope of Layer 2 communications to physical or virtual LANs, preventing frames from traversing routers, which operate at Layer 3 using IP addresses; inter-network traffic requires address resolution protocols like ARP to map IP to MAC for the final hop delivery. Special MAC addresses, such as the FF:FF:FF:FF:FF:FF, propagate frames to all devices on the segment for discovery or announcements, while addresses (with the least significant bit of the first octet set to 1) target groups for efficient distribution in protocols like . This addressing scheme underpins standards like Ethernet, ensuring collision-free or managed access in shared media environments via with (CSMA/CD) in half-duplex modes.

Integration with Protocols like ARP

The (ARP), standardized in RFC 826 in November 1982, relies on MAC addresses to resolve IPv4 addresses to corresponding hardware addresses within a , enabling Ethernet frames carrying IP packets to reach their local destinations. ARP operates by encapsulating its messages in Ethernet frames, where the source MAC address identifies the querying device and the destination MAC address is set to the broadcast value 01:00:5e:00:00:00 for the link-layer header in requests, ensuring all devices on the segment receive the query. This broadcast mechanism, integral to ARP's design, leverages the universal/local bit in the MAC address (the second-least significant bit of the first octet) to distinguish individual addresses from group communications, though ARP requests specifically use the reserved broadcast form ff:ff:ff:ff:ff:ff in the payload fields for target hardware addresses during initial resolution. Within the ARP packet structure, fixed fields explicitly include 6-byte hardware addresses for both sender and target, with the sender's MAC populated in requests to allow responders to reply directly via Ethernet framing using that MAC as the destination. In an ARP reply, the queried device's MAC address fills the sender hardware address field, completing the resolution and populating local ARP caches (typically holding up to 256-1024 entries depending on ) to avoid repeated broadcasts for subsequent communications. This tight coupling ensures causal linkage between layer-3 and layer-2 frame delivery, as unresolved MACs prevent frame transmission; empirical network traces confirm ARP failures manifest as packet drops, with broadcast storms possible if caches lack entries or duplicates arise from misconfigurations. Similar integration occurs in related protocols, such as the Inverse ARP (InARP) extension defined in RFC 2390 for non-broadcast media like , where DLCI identifiers map to MAC-equivalent addresses, or in RFC 1027, which allows routers to respond on behalf of remote hosts using their own MAC in replies to mask subnet boundaries. For IPv6, the (NDP) in RFC 4861 mirrors ARP by using solicited-node MAC addresses derived from IPv6 targets (e.g., 33:33:xx:xx:xx:xx prefix) for neighbor solicitation messages, embedding link-layer addresses in options to achieve stateless autoconfiguration and duplicate address detection without relying on broadcast. These protocols underscore MAC addresses' foundational role in address resolution, with deviations (e.g., in virtualized environments per RFC 9161) requiring explicit mediation to preserve across bridged domains.

Usage in Wired and Wireless Standards

In IEEE 802.3 Ethernet standards, which define wired operations across speeds from 1 Mb/s to 400 Gb/s, MAC addresses serve as the primary identifiers at the media access control (MAC) sublayer of the . Each Ethernet frame includes a 48-bit destination MAC address followed by a 48-bit source MAC address, enabling devices to determine frame delivery within the local network segment. These addresses support communication to specific devices, multicast to groups via addresses with the least significant bit of the first octet set to 1, and broadcast to all devices using the all-ones address (FF:FF:FF:FF:FF:FF). The frame format relies on these MAC addresses for with (CSMA/CD) in half-duplex modes or full-duplex operations without contention, ensuring reliable frame transmission over twisted-pair, fiber, or coaxial media. Universally administered MAC addresses, assigned via the IEEE Registration Authority, predominate, though locally administered addresses can be configured for specific network needs. In wireless standards, MAC addresses perform analogous roles but accommodate and ad-hoc topologies, with frames supporting up to four 48-bit address fields to handle scenarios involving access points (APs) and stations. The basic service set identifier (BSSID) is typically the AP's MAC address, uniquely identifying the wireless cell, while probe requests and association frames use source and destination MACs for discovery and connection establishment. Unlike Ethernet's two-address frames, 802.11 data frames in mode designate fields for receiver (next-hop station), transmitter (forwarding AP), destination (end recipient), and source (originator), facilitating meshed or relayed transmissions. The 802.11 MAC sublayer employs these addresses within carrier sense multiple access with collision avoidance (CSMA/CA) mechanisms, including request-to-send/clear-to-send (RTS/CTS) handshakes that incorporate MACs to mitigate hidden node problems. Multicast and broadcast frames, identified by group addresses, enable efficient distribution to multiple stations, with the standard mandating support for globally unique 48-bit addresses alongside protocol extensions for power management and quality of service. Both wired and wireless standards under IEEE 802 leverage MAC addresses for layer-2 switching and bridging, with Ethernet bridges forwarding based on learned MAC tables and Wi-Fi APs performing similar functions in extended service sets.

Security and Privacy Considerations

Device Tracking and Identification Risks

MAC addresses serve as persistent, unique hardware identifiers for network interfaces, enabling the tracking and identification of devices across when exposed in unencrypted frames like Wi-Fi probe requests and beacons. These frames, broadcast to discover available , reveal the MAC address to any passive listener within radio range, allowing correlation of a single device's movements over time and space without user consent or authentication. This capability has been exploited in various applications, including retail analytics where vendors deploy Wi-Fi sniffers to log MAC addresses for profiling customer behaviors, such as dwell times and visit frequencies, as documented in industry practices since at least 2013. In surveillance contexts, static MAC addresses facilitate targeted individual tracking; for example, a demonstration showed how Wi-Fi-based MAC monitoring could compute point-to-point travel times and infer user trajectories in urban environments, extending beyond vehicular traffic to pedestrian device carriers. and private entities have leveraged this for broader monitoring, with passive MAC collection at public hotspots enabling device fingerprinting that links hardware to specific users when combined with contextual data like location timestamps or repeated associations. The (OUI) portion of the MAC address further aids identification by revealing the manufacturer, narrowing device types (e.g., Apple vs. Android ecosystems) and potentially tying observations to vendor-specific behaviors. These risks are amplified in dense environments like cities or events, where widespread access point deployment creates comprehensive coverage; studies from onward confirm that non-randomized MACs allow long-term profiling, with probe requests alone sufficient for 80-90% accuracy in re-identifying devices across sessions in controlled tests. Incidents, such as Apple's 2023 revelation of devices inadvertently transmitting true MAC addresses alongside randomized ones in certain scenarios, underscore implementation flaws that expose users to unintended tracking by network operators or eavesdroppers. Without countermeasures, this exposes individuals to unauthorized , commercial exploitation, and potential linkage to personal identities via cross-referenced sources, as evidenced by academic analyses of analytics distortions from unmitigated MAC persistence.

Spoofing Vulnerabilities and Mitigation

MAC address spoofing involves an attacker altering the MAC address transmitted by their network interface to impersonate a legitimate device, exploiting the lack of inherent in Layer 2 Ethernet frames. This arises because MAC addresses are not cryptographically protected; operating systems and drivers permit software overrides of the hardware-burned address, enabling tools like on or registry edits on Windows to facilitate changes without hardware modification. In Ethernet networks, switches forward frames based solely on learned MAC addresses in their (CAM) tables, allowing a spoofed address to redirect traffic intended for the original device, as demonstrated in attacks where duplicate MACs cause frame misdirection. The primary risks include bypassing access control lists (ACLs) that filter by MAC, enabling unauthorized network entry in environments relying on static MAC whitelisting, such as campus or enterprise LANs. Spoofing facilitates ARP poisoning, where gratuitous ARP replies with the spoofed MAC associate an attacker's interface with a victim's IP, enabling man-in-the-middle (MITM) interception of traffic; this has been a vector in documented Layer 2 attacks since at least the early . In wireless networks, unencrypted management frames exacerbate spoofing, permitting identity forgery for deauthentication attacks or , with (RSSI) variations often detectable but not always enforced. Such exploits can lead to , denial-of-service via CAM table exhaustion (if combined with flooding), or evasion of intrusion detection systems tuned to known MACs. Mitigation strategies focus on network-level validation rather than endpoint enforcement, as client-side prevention (e.g., driver-level disabling) is unreliable against rootkits or physical access. Cisco Catalyst switches implement port security to restrict ports to one or a few learned MAC addresses, using "sticky" learning to bind dynamically observed addresses and shut down violating ports; violation modes include protect (silent drop) or restrict (alert and drop), effective against single-spoof attempts but vulnerable to multi-MAC flooding if limits are high. Dynamic ARP Inspection (DAI) cross-checks ARP packets against a DHCP snooping database of IP-MAC-port bindings, discarding mismatches to block spoofed ARP replies, with rate limiting to prevent exhaustion attacks; deployed since IOS versions around 2005, it requires enabling DHCP snooping upstream. Additional layered defenses include IP Source Guard, which filters inbound traffic by validated IP-MAC bindings from , and port-based authentication, which ties access to credentials rather than MAC alone, using EAP methods for mutual verification. In wireless contexts, RSSI fingerprinting detects spoofing by correlating signal patterns inconsistent with the claimed device's location, as validated in studies showing over 90% accuracy in controlled environments, though environmental noise reduces efficacy. Network monitoring tools can flag rapid MAC changes or duplicates via or SNMP traps, but comprehensive prevention demands segmenting untrusted ports and avoiding sole reliance on MAC for , as no single IEEE standard mandates spoofing resistance due to the address's design for local, non-routable identification. These measures, while reducing , introduce overhead like increased CPU load on switches during inspection, necessitating careful configuration in high-traffic deployments.

MAC Randomization Implementations

MAC randomization implementations primarily occur at the operating system level for client devices, generating temporary addresses derived from randomized values within the locally administered MAC address space (second least significant bit of the first octet set to 1) to obscure the device's permanent hardware identifier during network discovery, association, and data exchange phases. These implementations typically maintain a consistent randomized MAC per network profile to ensure connectivity stability, while regenerating the address periodically (e.g., every 24 hours or upon disconnection/reassociation) or for entirely new networks to mitigate tracking risks. Apple's introduced MAC randomization in version 8.0 (September 2014) initially for probe requests in the unassociated state, but expanded it to the association phase and made it the default for new Wi-Fi networks in (September 2020), , and subsequent releases including and later. In these systems, each SSID receives a unique randomized MAC, preserved across sessions for the same network but regenerated for untrusted or public ones, with further enhancements in 16.1 (October 2022) extending randomization to additional frame types on supported chips. Users or administrators can disable it via settings or MDM policies for managed devices, though it remains only for privacy-focused defaults. Google's Android implemented MAC randomization as an optional developer feature in Android 9 (August 2018), becoming enabled by default for new Wi-Fi networks in (September 2019) and standardizing per-network persistence with re-randomization triggers such as every 24 hours, device reboot, or network profile reset. The Android Open Source Project specifies that randomized addresses are generated using a hash of network parameters (e.g., SSID and BSSID) combined with a , ensuring uniqueness and avoiding collisions while supporting enterprise features like certificate-based . Device manufacturers may vary exact behaviors, but core randomization applies to both probe and association frames, with options to revert to hardware MAC for specific networks via advanced settings. Microsoft Windows supports random hardware addresses starting in Windows 10 (version 1803, April 2018), configurable per Wi-Fi network or globally under Settings > Network & Internet > Wi-Fi > Manage known networks > Properties > Privacy, where enabling it substitutes the device's MAC with a randomized one for outbound frames. This feature randomizes during connection to new networks and can be toggled to refresh the address, aiding privacy on public Wi-Fi but potentially complicating network management tools reliant on static identifiers. IEEE 802.11 standards do not mandate randomization but acknowledge its prevalence through study groups since 2014, with IETF documents like RFC 9724 (March 2025) cataloging interoperability impacts and recommending network adaptations such as probing for stable identifiers in enterprise environments. Implementations across these platforms prioritize locally administered addresses to comply with OUI allocation rules while avoiding interference with globally unique ranges.

Criticisms and Trade-offs of Randomization

MAC address randomization, while intended to enhance by obscuring persistent device identifiers, has been criticized for its incomplete protection against tracking. Studies demonstrate that attackers can still correlate randomized MAC addresses with other probe request attributes, such as sequence numbers, information elements, or timing patterns, enabling device fingerprinting across networks. For instance, research from 2016 showed that management retain sufficient stable data to defeat randomization in practice, undermining its core goal. Subsequent analyses in 2019 confirmed persistent vulnerabilities, including the "No-at-All" attack exploiting unrandomized elements in . A primary trade-off involves network usability and reliability, as randomization disrupts systems dependent on static MAC addresses for and policy enforcement. In enterprise environments, mobile device management tools fail to consistently identify or provision devices, leading to recognition errors and communication breakdowns during address changes. Home networks face similar issues, where features like , whitelisting, or bandwidth allocation break, requiring manual reconfiguration or disabling randomization per network. Frequent regenerations—often per connection or daily—can trigger repeated attempts, increasing latency, failed logins, and service interruptions, particularly in captive portals or enterprise Wi-Fi. Randomization also complicates network diagnostics, analytics, and optimization. Service providers report challenges in device identification for troubleshooting or QoS enforcement, resulting in fragmented usage data and suboptimal performance allocation. While collision risks from randomized addresses remain low in typical deployments (e.g., probability below 0.1% in networks under 1,000 devices), they introduce minor overhead in dense environments. Overall, these drawbacks pit privacy gains against operational stability, prompting recommendations for selective disabling in trusted networks or hybrid approaches combining randomization with higher-layer mitigations.

Notational and Implementation Conventions

Standard Hexadecimal Representations

The standard representation of a 48-bit MAC address (also known as MAC-48 or EUI-48) consists of twelve digits, divided into six pairs of two digits each, where each pair corresponds to one octet in order. This format displays the octets from left to right without reversing the bits within each octet, reflecting the sequence as stored in or transmitted (with the least significant bit of each octet sent first on the wire, but hex conversion preserving standard binary ordering). digits range from 0-9 and A-F (case-insensitive, though uppercase is conventional in most documentation). In documentation, hyphens (-) serve as the separator for this canonical hexadecimal notation, yielding formats like AC-DE-48-00-00-02. This distinguishes it from bit-reversed variants, ensuring clarity in technical specifications. For instance, the assigns Organizationally Unique Identifiers (OUIs) in this hyphenated , with the first three octets typically representing the OUI followed by three octets for the device-specific portion. Although IEEE reserves colons (:) for bit-reversed representations (e.g., reversing bits per octet before hex conversion), colons are commonly adopted in practice for addresses across networking tools, operating systems, and IETF documents, such as ac:de:48:00:00:02. This widespread use stems from readability preferences in software like or outputs, despite deviating from strict IEEE separator conventions for reversal indication. Both separators maintain the same underlying 48-bit value, serving solely for human parsing; unambiguous parsing requires context or validation against known OUIs.

Bit-Reversed and Other Notations

The bit-reversed notation, also known as non-canonical or Token Ring format, represents each octet of a MAC address by reversing the order of its eight bits before converting the result to hexadecimal digits. For example, the octet 0x1A (binary 00011010) becomes 0x58 (binary 01011000) after bit reversal, transforming a standard MAC address like 1A:2B:3C:4D:5E:6F into 58:D4:3C:B2:7A:F6. This format arose due to differences in bit transmission order: Ethernet sends bits least-significant-bit (LSB) first within each octet, while Token Ring networks transmit most-significant-bit (MSB) first, necessitating bit reversal for consistent display or compatibility in mixed environments. It is now rarely used outside legacy systems, as IEEE 802 standards favor the canonical format aligned with Ethernet's transmission order. In the canonical (standard) notation, MAC addresses are displayed as six pairs of hexadecimal digits separated by colons (e.g., aa:bb:cc:dd:ee:ff) or hyphens (e.g., aa-bb-cc-dd-ee-ff), reflecting the octet values in the order of transmission bytes, with hex digits typically in lowercase or uppercase indifferently. Alternative separators include periods in Cisco IOS displays, grouping every four bits (e.g., aabb.ccdd.eeff) for readability in command-line interfaces, though this is non-standard for general use. Unseparated hexadecimal strings (e.g., aabbccddeeff) or decimal representations are occasionally employed in programming or databases but lack standardization and can lead to parsing errors. The IEEE recommends colon-separated canonical form to avoid ambiguity, particularly when distinguishing bit order in protocols like IEEE 802.

Practical Implementations Across Devices

In network interface controllers (NICs) for personal computers and servers, MAC addresses are embedded in hardware during manufacturing, typically stored in ROM or EEPROM on Ethernet controllers compliant with IEEE 802.3 standards, enabling source and destination addressing in Ethernet frames for local area network communication. Manufacturers obtain blocks of addresses from the IEEE Registration Authority, where the first 24 bits form the Organizationally Unique Identifier (OUI), and the remaining 24 bits are uniquely assigned by the vendor to each NIC. Wireless devices, including adapters in laptops and integrated modules in smartphones, implement MAC addresses similarly in their chipsets for protocol operations, such as association requests and frame acknowledgments; for instance, baseband processors in devices like or chips use the hardware MAC as the foundation for link-layer identification. In smartphones, operating systems like Android derive per-network randomized MAC addresses from this base hardware identifier to mitigate tracking, but the underlying silicon-level implementation remains fixed and manufacturer-assigned.
Routers and switches allocate unique MAC addresses to each physical or virtual interface from vendor-assigned blocks, facilitating layer-2 forwarding and ARP resolution; devices, for example, derive interface MACs sequentially from a base address burned into the system, with one address per Ethernet port plus additional for management functions. This ensures distinct identification in bridged or switched domains, as required by bridging standards. In IoT devices, MAC addresses are integrated into chips for wireless connectivity, such as in Espressif modules where the 48-bit address is fused into the memory during fabrication, allowing retrieval via APIs for or provisioning while supporting local modifications for testing. These implementations prioritize low-power operation, with the MAC enabling direct device-to-device or access point communication in standards like for certain sensor networks. Across all device types, the second least significant bit of the first octet distinguishes universally administered (factory-set) from locally administered addresses, allowing network operators to override defaults for redundancy or .

References

  1. https://www.7signal.com/media-access-control-mac-address
  2. https://synchronet.net/mac-address-format/
  3. https://bluecatnetworks.com/blog/mac-address-vs-ip-address-whats-the-difference/
  4. https://www.geeksforgeeks.org/computer-networks/mac-address-in-computer-network/
  5. https://standards.ieee.org/products-programs/regauth/
  6. https://standards-support.ieee.org/hc/en-us/articles/4888705676564-Guidelines-for-Use-of-Extended-Unique-Identifier-EUI-Organizationally-Unique-Identifier-OUI-and-Company-ID-CID
  7. https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/macgrp.pdf
  8. https://www.ieee802.org/1/files/public/docs2020/yangsters-smansfield-mac-address-format-0420-v01.pdf
  9. https://www.geeksforgeeks.org/computer-networks/mac-full-form/
  10. https://standards.ieee.org/products-programs/regauth/oui28/
  11. https://ethw.org/Milestones:Ethernet_Local_Area_Network_%28LAN%29%2C_1973-1985
  12. https://ewh.ieee.org/r6/oeb/comsoc/Past_Presentations/EthernetHistory_NetWorkshop_Mar04.pdf
  13. https://www.networkworld.com/article/723527/lan-wan-living-legends-ethernet-inventor-bob-metcalfe.html
  14. https://www.globalknowledge.com/us-en/resources/resource-library/articles/does-a-mac-address-mean-apple-invented-it/
  15. https://akapugs.blog/2020/02/12/676/
  16. https://www.sciencedirect.com/topics/computer-science/ethernet-address
  17. https://www.sciencedirect.com/topics/computer-science/mac-address
  18. https://standards.ieee.org/featured/ieee-802/
  19. https://standards.ieee.org/beyond-standards/ethernet-50th-anniversary/
  20. https://standards.ieee.org/products-programs/regauth/oui/
  21. https://standards.ieee.org/faqs/regauth/
  22. https://datatracker.ietf.org/doc/html/rfc7043
  23. https://www.ieee802.org/1/files/public/docs2022/cq-marks-64-bit-address-v02.pdf
  24. https://standards.ieee.org/ieee/802c/6890/
  25. https://ieeexplore.ieee.org/document/8016709
  26. https://www.ieee802.org/1/files/public/docs2017/802c-Marks-summary-0917-r1.pdf
  27. https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization/08/
  28. https://support.apple.com/guide/security/privacy-features-connecting-wireless-networks-secb9cb3140c/web
  29. https://addigy.com/blog/randomized-mac-address-guide/
  30. https://petsymposium.org/2017/papers/issue4/paper82-2017-4-source.pdf
  31. https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf
  32. https://www.ietf.org/archive/id/draft-ietf-madinas-mac-address-randomization-08.html
  33. https://datatracker.ietf.org/doc/html/rfc7042
  34. https://www.rfc-editor.org/rfc/rfc9797.html
  35. https://datatracker.ietf.org/doc/html/rfc8948
  36. https://networkengineering.stackexchange.com/questions/23566/what-are-eui-48-and-eui-64
  37. https://www.ieee802.org/secmail/msg00396.html
  38. https://standards.ieee.org/products-programs/regauth/mac/
  39. https://standards.ieee.org/wp-content/uploads/import/documents/forms/sgm_application.pdf
  40. https://regauth.standards.ieee.org/
  41. https://standards.ieee.org/products-programs/regauth/infocx/
  42. https://macaddresslookup.io/blogs/what-is-the-difference-between-locally-administered-and-universally-administered-mac-addresses
  43. https://mentor.ieee.org/802-ec/dcn/17/ec-17-0174-00-00EC-ieee-802-tutorial-of-2017-11-06-local-mac-addresses-in-the-overview-and-architecture-based-on-ieee-std-802c.pdf
  44. https://www.ieee802.org/1/files/public/docs2016/c-rev-d0-1-DIS.pdf
  45. https://edc.intel.com/content/www/us/en/design/products/ethernet/adapters-and-devices-user-guide/29.2.1/locally-administered-address/
  46. https://support.huawei.com/enterprise/en/doc/EDOC1100276757/d30cdf7f/overview-of-multicast-mac-addresses
  47. https://standards.ieee.org/products-programs/regauth/grpmac/public/
  48. https://networklessons.com/multicast/multicast-ip-address-to-mac-address-mapping
  49. https://mrncciew.com/2012/12/25/multicast-address-allocation/
  50. https://www.ieee802.org/1/files/public/docs2018/cq-aoliva-proposal-selfasignmenttext-0318.pdf
  51. https://standards.ieee.org/ieee/8802-A_2015_Amd_2/10067/
  52. https://notes.networklessons.com/mac-address-of-all-zeros
  53. https://www.iana.org/assignments/ethernet-numbers
  54. https://jumpcloud.com/it-index/understanding-layer-2-the-data-link-layer-of-the-osi-model
  55. https://www.ieee802.org/3/as/public/0503/4d0_1_CMP.pdf
  56. https://ieeexplore.ieee.org/document/9844436
  57. https://www.ciscopress.com/articles/article.asp?p=3089352&seqNum=6
  58. https://community.cisco.com/t5/networking-knowledge-base/network-switching-operation/ta-p/4193160
  59. https://www.globalknowledge.com/us-en/resources/resource-library/articles/how-switches-work/
  60. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_arp/configuration/15-s/arp-15-s-book/Configuring-Address-Resolution-Protocol.html
  61. https://standards.ieee.org/ieee/802.3/10422/
  62. https://www.ibm.com/support/pages/ethernet-version-2-versus-ieee-8023-ethernet
  63. https://www.scoredetect.com/blog/posts/ethernet-mac-standards-explained
  64. https://www.networkacademy.io/ccna/wireless/802-11-frame-addressing
  65. https://community.nxp.com/t5/Wi-Fi-Bluetooth-802-15-4/802-11-Wi-Fi-Basic-concepts/ta-p/1124409
  66. https://people.cs.pitt.edu/~xex1/Courses/WirelessNets/Materials/Feb13-WirelessLAN-2-v2.pdf
  67. https://grouper.ieee.org/groups/802/11/Documents/DocumentArchives/1991_docs/1191035_scan.pdf
  68. https://inria.hal.science/hal-00858324/document
  69. https://www.schneier.com/blog/archives/2021/09/tracking-people-by-their-mac-addresses.html
  70. https://ieeexplore.ieee.org/document/10550935
  71. https://onlinelibrary.wiley.com/doi/10.1155/2017/6235484
  72. https://telefonicatech.com/en/blog/privacy-breach-apple-devices-sending-real-mac-of-the-device-along-random-one
  73. https://www.cablelabs.com/blog/mac-address-randomization-how-user-privacy-impacts-wi-fi-and-internet-service-providers
  74. https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/72846-layer2-secftrs-catl3fixed.html
  75. https://www.securew2.com/blog/how-do-mac-spoofing-attacks-work
  76. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst_pon/software/configuration_guide/sec/b-gpon-config-security/preventing_arf_spoofing_and_flood_attack.pdf
  77. https://ieeexplore.ieee.org/document/4509834
  78. https://source.android.com/docs/core/connect/wifi-mac-randomization
  79. https://www.ietf.org/archive/id/draft-ietf-madinas-mac-address-randomization-15.html
  80. https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior
  81. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Meraki_and_MAC_Address_Randomization
  82. https://petsymposium.org/popets/2021/popets-2021-0042.pdf
  83. https://support.apple.com/en-ca/guide/security/secb9cb3140c/web
  84. https://www.miradore.com/knowledge/ios/disabling-wi-fi-mac-address-randomization-on-iphones-or-ipads/
  85. https://community.spiceworks.com/t/android-12-mac-randomization-a-different-mac-address-every-24-hours/965938
  86. https://www.esper.io/blog/how-to-disable-mac-randomization-on-android
  87. https://forensic4cast.com/2022/02/mac-randomization-in-windows/
  88. https://windowsforum.com/threads/enhancing-privacy-on-windows-how-to-use-random-hardware-addresses.350821/
  89. https://community.spiceworks.com/t/beyond-the-obvious-what-does-the-randomize-hardware-address-do-in-win10/931089
  90. https://datatracker.ietf.org/doc/rfc9724/
  91. https://papers.mathyvanhoef.com/asiaccs2016.pdf
  92. https://www.researchgate.net/publication/336545176_Five_Years_Later_How_Effective_Is_the_MAC_Randomization_in_Practice_The_No-at-All_Attack
  93. https://www.hexnode.com/blogs/mac-address-randomization/
  94. https://purple.ai/blogs/mac-randomization-network
  95. https://cujo.com/blog/the-true-impact-of-mac-randomization-on-network-service-operators/
  96. https://www.linkedin.com/pulse/randomized-mac-address-collision-analysis-baw-chng
  97. https://www.extremenetworks.com/resources/blogs/wi-fi-mac-randomization-privacy-and-collateral-damage
  98. https://macaddress.io/faq/notational-conventions
  99. https://www.ibm.com/docs/en/csfdcd/7.1.0?topic=ls-bit-ordering-in-mac-addresses
  100. https://www.ionos.com/digitalguide/server/know-how/mac-address/
  101. https://www.vultr.com/resources/mac-converter/
  102. https://www.pathsolutions.com/blog/mac-addresses-not-a-cheesy-subject
  103. https://standards.ieee.org/wp-content/uploads/2024/10/ieee-mac-address.pdf
  104. https://community.cisco.com/t5/networking-knowledge-base/network-tables-mac-routing-arp/ta-p/4184148
  105. https://grouper.ieee.org/groups/802/1/files/public/docs2014/New-pannell-MAC-Address-Issues-in-802dot1-1114-v1.pdf
  106. https://mentor.ieee.org/802.15/dcn/24/15-24-0396-00-006a-practical-aspects-of-solving-the-incompatibility-of-64-bit-mac-addresses-in-ieee-stds-802-15-with-the-ieee-std-802-1q-2022.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.