Talk:MAC address

Bytes, Octets and "Significance"

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)

I'm new to computer networking, But I found it hard to understand which value would be considered least or most significant for an octet. I'd love if that was defined better and quicker in the article (first spot I found it was in multicast transmissions. was used 2 other spots before that in unicast and Universal vs. local (U/L bit)) also that 0 = even since that's not specified (but 1=odd is specified in multicast) 50.92.161.150 (talk) 19:28, 28 October 2022 (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 72.172.171.178 (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)

After reading I was forced to look elsewhere for a definition of octets and bits (as I did for IP addressing on Wikipedia). A clear note to explain the octet as a hexadecimal representation of an 8 bit binary value might help. In addition, no mention here of BSSIDs, which are also MAC-48 values; nor of (claimed?) deobfuscation of MAC addresses by websites are thereby beyond local networks. The Apple iPhone mention seems advertising given the widespread default spoofing in much software these days (including Windows 10 Settings where default randomization can be ticked, and Linux Network Manager, which randomizes by default and has to be disabled in its configuration file to allow user MAC control). 94.118.87.120 (talk) 20:42, 21 November 2018 (UTC)

In almost all cases, MAC addresses are bit strings, matched for equality. There is no most or least significant bit. The exception is Spanning Tree Protocol, where it is used as a tie breaker in assigning links to the spanning tree. Part of the confusion is that the hardware puts bits on the wire, byte by byte, with the least-significant bit of each byte first. Gah4 (talk) 20:19, 28 October 2022 (UTC)

I do not understand why some examples in this article are 10 digits long.

Did someone forget the last -XX? Bluessound (talk) 11:00, 2 November 2023 (UTC)

Suspect references

References number 26 and 27 are supposed to prove that it is possible to recognize a person given its mac address, or something along those lines. The first points to nothing while the second just looks irrelevant to me. 92.134.33.82 (talk) 12:28, 29 September 2023 (UTC)

Ref 26 says that it is not accessible. Ref 27 doesn't say that it is known to recognize someone, only that they can make it harder. If I decide to lock my door, that doesn't mean that I know anyone is actually trying to go in. For high value targets, and well funded organizations, I suspect it is possible. Also, if government organizations have deals with ISPs, they can pass along information. For ordinary users, I suspect it isn't a problem. But how do you know if you are ordinary enough? Gah4 (talk) 19:58, 29 September 2023 (UTC)

Using Google to search for the title of reference 26 in quotes shows the original at springer and researchgate. I don't know what the ref says but nordvpn says that a company tried to track people "with smart trash cans in London". Ref 26 is also archived here. Johnuniq (talk) 03:52, 30 September 2023 (UTC)

Ranges of group and locally administered addresses

Why do the ranges specified only have five octet addresss e.g. X2-XX-XX-XX-XX? 2A00:23C4:DB3D:E901:90CA:4ED5:72C:E339 (talk) 12:19, 20 November 2023 (UTC)

@2A00:23C4:DB3D:E901:90CA:4ED5:72C:E339: Apparently a typo – fixed. --Zac67 (talk) 13:53, 20 November 2023 (UTC)