Talk:MAC address

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as High-importance).
This article has been mentioned by a media organization:

Bytes, Octets and "Significance"[edit]

I don't believe there is any concept of Least or Most Significant Byte in MAC addresses. There are merely the first octet through the nth octet (6 or 8). The standard only speaks of octets, and octets are transmitted in order one by one. The standard *does* assume a significance of bits within an octet, and specifies physical-layer transmission bit-order and the I/G and U/L bits in terms of "Least Significant Bit". But there is no "significance" of bytes in MAC addresses; they are merely identifiers; there is no concept of arithmetic with them; their essential property (as far as the protocol is concerned) is uniqueness only. (The separation of part of the address into an OUI is for convenience of human administration and is not essential to the protocol.) -- Dave Butterfield (talk) 00:54, 21 February 2009 (UTC)

I agree, but what is your point? Who/what are you directing this towards? JeremyWJ (talk) 04:42, 21 February 2009 (UTC)
This section is full of double negatives and is kind of confusing too 15:42, 19 June 2009 (UTC-7) —Preceding unsigned comment added by (talk)

I agree here with Dave. The third and fourth paragraphs are very confusing on this point and should be rewritten. The diagram is also just wrong (no byte significance, no opposite byte/order direction, no fixed bit order transmission). And these points are quite important when trying to understand the Bluetooth protocol as in this special case, octets are transmitted in the wrong order (though BT spec pretends to be complying with IEEE 802-2001). It would be actually interesting to add a new paragraph ("transmission order") explaining these subtleties. Calandoa (talk) 16:23, 15 March 2016 (UTC)

In various places, the text refers to "most significant byte", "most significant address octet", both mixing the 2 terms and assuming significance. In my opinion, there is absolutely no need to confuse people with byte order in this instance, and a lot of confusion could be avoided by always referring to the octets by their order on the wire, "First octet" being the first one transmitted, etc. There is a diagram that labels the first octet on the wire as both "6th byte" and "1st octet", as well as labeling the first byte as "most significant". This seems completely wrong to me and can only lead to confusion. I propose the "Address details" section be rewritten to avoid all references to byte order. It seems there is some agreement on this so I will try to do this. Catphish (talk) 10:32, 6 June 2016 (UTC)

I've now done this. I've simplified the diagram, fixed the numbering of bits to start at zero, and removed any reference to byte order. I hope everyone is happy with this. I didn't see an immediate need for a major rewrite. Catphish (talk) 10:46, 6 June 2016 (UTC)

Internal format of MAC[edit]

There is some formats of MAC addresses, I've read about them in "Computer Networks" by Andrew Tanenbaum.

Is it possible for a PC to lose its MAC address configuration permanently? What I mean is, my PC crashed during a thunderstorm, after it came back on I could no longer access my network at home. Which is using DHCP. When I brought it to my office and connected it to my LAN I was able to connect. I also connected it directly into a device that is using DHCP and the PC recognized the connection. I then brought the PC home and reconnected it, in the hope that by some slim chance it would work, it did not. So that is why I am asking if it is possible for a PC to permanently lose a MAC address.

From your description, the PC sounds fine. More likely, the router box providing DHCP leases for IP addresses has a problem. A number ISP provided home routers seem to suffer from a "no more IP addresses for you" problem. Usually power cycling the router will clear the problem. Of course, another problem could be a physical cabling problem. Also As your router box is likely connected directly to cables which run outside, this box could be suffering as a result of lightning from the thunderstorm.Lent (talk) 19:32, 25 January 2010 (UTC)

Fixed finding MAC under Windows XP[edit]

The instructions for finding the MAC address under Windows XP recommended using arp -a, which shows the MAC of other machines on the Local Area Network. The command ipconfig/all shows the MAC address for all network devices. David Harbaugh

The "arp -a" works fine if the network is working properly.
Sadly, the "arp -a" command can fail if:
  • the remote host is disconnected,
  • the remote host is off (except for Wake-on-LAN),
  • the remote host is on a different subnet,
  • Proxy ARP is in use,(you get the Proxy's MAC address instead)
  • the ARP/IP address pair has timed out and been purged from the local ARP table.
  • two hosts are trying to use the same IP address, so only the latest IP/ARP address pair is stored in the local ARP table,
  • a static ARP/IP address pair has been entered in the local ARP table, so new MAC addresses for the static IP address are just tossed away,
  • the remote system is running a protocol like DECnet which uses a locally administered address, so the "burned in" address isn't seen
  • the local host is not running the TCP/IP protocol :-)
To attempt to get a MAC address on a remote subnet, say across a router,
the NBTSTAT -A IP address and NBTSTAT -a remote_SMB_hostname commands will retrieve the remote MAC address for many systems, but Samba systems respond back with MAC Address = 00-00-00-00-00-00 instead.Lent (talk) 16:45, 25 January 2010 (UTC)

Finding a MAC address[edit]

I needed to find various MAC addresses of a GNU/Linux and a Mac OS X machine. This involved taking one external link from this article, finding that it was irrelevant, taking another, finding that the explanation was outdated and/or obscure, and finally:

sudo ifconfig -a

I noticed in passing that with a Windows machine that's not grotesquely unsuited for today's internet, the command would be

ipconfig /all|more

I realize that WP is not a compendium of "howto" manuals, but suggest that this information would be useful and worth inclusion in the article. Comments? -- Hoary (talk) 07:16, 23 January 2010 (UTC)

Agreed. Added what is hopefully a stable non-commercial link under .gov. Darrell_Greenwood (talk) 03:33, 25 January 2010 (UTC)
Here's a search that yields ".edu" sites for these types of instructions.Lent (talk) 16:57, 25 January 2010 (UTC)
To answer the original question:
arp -i eth0 -n
will show the mapping from IP addresses to MAC addresses on your local network. — Preceding unsigned comment added by (talk) 14:36, 25 August 2011 (UTC)

Do all WiFi capable devices have a MAC address?[edit]

I'm doing some research into a potential software product and need to understand if all WiFi enabled products have a unique MAC address. By this I mean games consoles, phones, PDAs etc etc. (talk) 13:25, 18 February 2010 (UTC)

Any device which transmits 802.11 frames must use a MAC address. In theory, a device could ship without a pre-programmed ("burned in"), Universally Administered Address (UAA), requiring the operator to enter a Locally Administered Address (LAA), but it would still need a MAC address. Practically everything which can transmit ships with a UAA pre-programmed. Passive devices which only listen/monitor do not need a MAC address. • If you're researching a commercial application, you should hire a professional engineer, rather than trusting what random people on Wikipedia say. —DragonHawk (talk|hist) 14:23, 18 February 2010 (UTC)

Bit 1 is the least significant bit?![edit]

As far as I know, absolutely no software engineers call the least significant bit bit 1. The value of a bit is 2 raised to the power of the bit number, therefore the least significant bit is bit 0. Calling the least significant bit "bit 1" just creates confusion and reduces the perceived competence of the author. Also, "Universally administered and locally administered addresses are distinguished by setting the second least significant bit of the most significant byte of the address", contradicts the diagram. The diagram says that the least significant bit determines whether it is multicast. —Preceding unsigned comment added by (talk) 17:24, 11 April 2010 (UTC)

More sub-headings ?[edit]

Could we perhaps add some sub-headings to make it easier to locate subsections that deal with 'special' addresses and address types, such as say broadcast, multicast group? And maybe move EUI64 down into its own subsection with a subheading? I suggest that this would make the article more accessible. Thoughts? Suggestions for subheadings?

Could I perhaps get some help putting together a table of notable special/sacred numerical values, ranges too?CecilWard (talk) 16:39, 14 July 2010 (UTC)

Is There a Way to Make This More Understandable to Non-Computer Science Students?[edit]

"A Media Access Control address (MAC address) is a unique identifier assigned to network interfaces for communications on the physical network segment. MAC addresses are used for numerous network technologies and most IEEE 802 network technologies including Ethernet. Logically, MAC addresses are used in the Media Access Control protocol sub-layer of the OSI reference model."

Glad I asked,thanks a lot ! (talk) 18:11, 24 November 2010 (UTC)
Try this: --2001:980:A4CB:1:7D09:88D5:B721:DAEB (talk) 19:21, 7 April 2013 (UTC)

On what goes in the Externals list[edit]

I notice a bit of revert controversy from time to time regarding whose MAC address lookup sites to include in the externals list. My feeling is, the fewer the better, otherwise everyone and his dog will say "you have all those, why is it fair not to include my MAC address information page also?"

On the specific subject of Michael Patton's "Ethernet Codes Master Page", user Kvng commented when reverting a removal of the link, "don't delete links just because they're dead. see WP:ROT". But I feel it is worth mentioning that WP:ROT has some very specific wording on this subject: "Except for URLs in the External links section that have not been used to support any article content, do not delete a URL solely because the URL does not work any longer." With the emphasis on solely and the explicit exception covering Externals, it almost seems that WP:ROT has been written specifically to allow for cleaning dead links out of the Externals section without further ado. On the other hand, I was able to find the new URL easily, and the content seems to be relatively useful and non-commercial, and the URL seems to be the proper canonical source for the material.

But in general, if the trend continues, the Externals section will decay into all kinds of duplication and link spam. I foresee a need for some rules on what to include. I'm not an expert editor, so I don't know what's proper. Maybe someone should post links to guidelines here? JMCorey (talk) 21:14, 22 June 2011 (UTC)

You are right. An IP poster had an external link to a ad-ladened site reverted by DragonHawk on June 13 and may be deleting everything in retaliation. I reverted the IP poster as did Kvng (the ISP in the three instances is CHONGQING PROVINCE NETWORK).
I spent some time reviewing the external links subsequently to make sure they were reasonable. I made a close judgement call that although the Michael Patton's "Ethernet Codes Master Page" link was available on cavebear's archive page, 1. the page itself was a mirror and the original is gone, 2, almost all the links were broken on the landing page, so I felt I wasn't doing anybody a favour by leaving it in, just a bunch of confusion. I've changed my mind and agree with your and Kvng's consensus to leave it in.
Each of the other external links seemed to have something different and unique to contribute when I reviewed them, especially the last one with access to Google's geolocation database. Darrell_Greenwood (talk) 23:15, 22 June 2011 (UTC)

Is the MAC Address transmitted via the Browser?[edit]

I read the article and could not find an answer to the question above. It has to do with Internet Browsing Security and Anonymity. I've read some posts that indicate at least some people believe this information is given out when one browse's the internet, so that a person's computer's identity can be recorded as having visited a particular site, etc...

Yet, I've never read anything from any reputable Computer Security organization that discusses the need to monitor and control the MAC Address (vs. cookies, flash cookies, IP Address, etc...)

Is the MAC Address a threat to one's anonymity and/or security? My sense is that it is not, and that it is only used and made available within the local network, and once the computer is outside that network, the external IP of the router/modem is the only identifying information that can been seen.

````Jonny Quick — Preceding unsigned comment added by Jonny Quick (talkcontribs) 14:51, 13 August 2011 (UTC)

Questions like this should be at Wikipedia:Reference desk/Computing, but the answer is no. Privacy is threatened by the cookies and IP address you mentioned, and other ugly tricks which the refdesk can probably enumerate, but the MAC address of your modem/router (or possibly computer) are seen only by the ISP, and not anyone else. Apparently it is possible on a very insecure computer for something running in Internet Explorer to read a computer's MAC address, but on the network, your MAC address is only available at your ISP. Johnuniq (talk) 23:58, 13 August 2011 (UTC)
The above answer from Johnuniq (that the MAC address is not transmitted across the net) may be true for IPv4, but in the case of IPv6, it is less clear. There is some discussion of privacy in the IPv6 article. -- HLachman (talk) 19:50, 6 March 2016 (UTC)

IPv6 error[edit]

I have moved the following comment from the article. -—Kvng 16:33, 17 December 2012 (UTC)

IPv6 — one of the most prominent standards that uses a Modified EUI-64 — treats MAC-48 as EUI-48 instead (as it is chosen from the same address pool) and toggles the U/L bit (as this makes it easier to type locally assigned IPv6 addresses based on the Modified EUI-64). 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 U/L bit inverted.RFC 5342
Note: The last statements regarding IPv6 seem to be incorrect. The RFC referred to only contains a note that IETF treats MAC-48 as EUI-48, because that "doesn't cause any problems in practice". It does not specify that everyone else should be doing the same. -- (talk · contribs)


Is there any standard for labeling on equipment? I've seen barcodes used but I haven't found any indication that there's a standard for this. For example, here's a Code 128 label:

MAC address barcode 00-17-4F-08-5D-69
--SpareSimian (talk) 01:00, 21 December 2012 (UTC)
I'm not aware of any standard. There's certainly no requirement to print the MAC address on equipment. -—Kvng 17:24, 24 December 2012 (UTC)


Today I've learned that in this world of virtualization, MAC addresses are no longer globally unique. Best practice for virtualized environments requires only that MAC addresses be unique per subnet. Read the Setting up MAC addresses section of this VM documentation for a discussion of the new world order. They've not even bothered to recommend locally administered addresses. Eeek! ~KvnG 20:34, 15 July 2013 (UTC)

That is nothing new. MAC spoofing has been a common practice for decades. Spoofed MAC addresses in Windows did not require the "locally administered address" bit prior to Windows 7 and other operating systems continue to allow spoofing OUI MAC addresses to this date. Most home network products also allow complete freedom in spoofing their MAC. So, even the average home user has been perfectly capable of spoofing those "globally unique" OUI addresses for a long time. - (talk) 01:47, 2 April 2014 (UTC)


The article contains no information about the new OUI36! The IEEE has already begun to make reservations. — Preceding unsigned comment added by (talk) 19:53, 28 September 2013 (UTC)

Error - Locally Administered Address and Multicast flags place on wrong bits[edit]

8 bits in Most mean octet used for Locally Administered Address (LLA) and Multicast must be placed to 1st bit and 0 bit accordingly.

This is has simple logic - 1st bit what will be in wire it will be... surprised? bit numberd 40 (0 bit from 5th octet) - we get Multicast packet, and reducing overhead in switch hardware so. LLA simple placed on next bit.

Author possibly takes obsoleted info from link on old IEEE pdf file.

For proof: (this main - they referring to IEEE standard)

Anybody can check this with proven utility - wireshark, by editing MAC on own PC

If it will be need, I can to check this in Linux or FreeBSD source code. — Preceding unsigned comment added by Kosta.Shtabalyuk (talkcontribs) 00:37, 5 November 2013 (UTC)

I assume this comment refers to the figure in the MAC address#Address details section. The figure is correct. Over Ethernet, bytes are transmitted least significant bit first. The first bit transmitted indicates whether the address is multicast. ~KvnG 05:44, 7 April 2014 (UTC)

Canonical presentation format[edit]

The article claims

The standard (IEEE 802) format for printing MAC-48 addresses in human-friendly form is six groups of two hexadecimal digits, separated by hyphens (-) or colons (:)

but does not substantiate that claim with a reference. I have been able to find a couple of sources that promote the use of hyphens, but none that promote colons:

which both state

An EUI-48[64] is properly displayed as shown with hyphens between numbers in canonical address representation...

There is also:

which states:

The Address field MUST be represented as six two-digit hexadecimal numbers separated by hyphens.

Although the use of colons is common, I believe it is overreaching to claim that it is supported by a standard. It would be better to state that colons are commonly used as an alternative representation. — Preceding unsigned comment added by 2403:3400:6001:125:381E:C47D:8682:73F7 (talk) 05:40, 7 September 2015 (UTC)

I discovered that an earlier revision of this article made a distinction between standard and alternative notation. The elevation of the colon notation to "standard" was made (incorrectly in my opinion) in this edit.

That edit was by Kbrose who will be able to throw some light on the matter. The RFC 7043 mentioned above is for how an EUI-48 address should be stored in a DNS server and is not really relevant to this text which refers to a "human-friendly form". Please remember to sign comments with four tildes. Johnuniq (talk) 10:39, 7 September 2015 (UTC)

I got hold of the IEEE 802-2014 standard in which section 8.1 defines the hexadecimal representation which uses hyphens. A bit-reversed representation that uses colons is also defined and accompanied by a note that states "the bit-reversed representation is of historical interest only and is no longer applicable to any active IEEE 802 standard." The standard gives the following example of a particular MAC address represented both ways:

Hexadecimal representation: AC-DE-48-12-7B-80
Bit-reversed representation: 35:7B:12:48:DE:01

Clearly the bit-reversed representation is not the same as the hexadecimal representation with colons replacing hyphens and is therefore different from the colon representation that is seen more commonly. I believe this adds additional weight to the argument for having the article acknowledge only the hyphen representation as standard with other representations identified as non-standard alternatives. 2403:3400:6001:125:381E:C47D:8682:73F7 (talk) 16:12, 8 September 2015 (UTC)