Add private (LAA: Locally Administered Addresses) MAC address ranges
- Langage dominant
- Java
- Étoiles
- 5.1k
- Forks
- 835
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
This is a followup to issue #317, which was successfully closed with an update to the OUI database file. I made a note in that issue that there were still some MAC addresses not being identified, and that is still the case. I have some Apple devices that are configured to use a "private" per-network randomized MAC address. I gather from some internet commenters that this has also become common in Android devices for v10.x and up. So as time goes on there will be more and more of these MAC addresses that can't otherwise be identified.
I can't find an RFC specific to this but it seems to be widely agreed that there is a set of four possible MAC address patterns that designate a "Locally Administered Address", and that these semi-randomized MAC addresses used by Apple and Android (and sometimes virtual machines) will conform to one of these patterns:
```
x2‑xx‑xx‑xx‑xx‑xx
x6‑xx‑xx‑xx‑xx‑xx
xA‑xx‑xx‑xx‑xx‑xx
xE‑xx‑xx‑xx‑xx‑xx
```
I would like to see knowledge of these private (LAA) MAC address ranges added into the scanner so that it can show something slightly more useful than `[n/a]` for any of these devices, which is what v3.8.2 is still showing me (Ubuntu 21.10). The `[n/a]` should be reserved for public (ULA) MAC addresses that are just not included in the OUI database file yet, or maybe devices that have a spoofed MAC address that doesn't match anything in the OUI list, but also is not a private (LAA) address. Since the LAA ranges are known, `ipscan` should say so.
Suggested output in scan results if one of these private MAC addresses is found:
`[Private MAC address (LAA)]`
Googling `private mac address laa` actually comes up with several on-topic and informative links right on the first page of results, so given this output from `ipscan` users should have the ability to quickly reduce any confusion about why a particular device is not being identified with a MAC vendor. Keeping the square brackets around the result will hopefully also clue the user into the fact that this is a generic result provided internally by `ipscan` (like `[n/a]` and `[n/s]`), rather than coming from the list of MAC vendors.
According to Wikipedia, theoretically all that is necessary to detect that any MAC address is in the private range(s) is to test the second-least-significant bit in the first octet of the MAC address, aka the "U/L bit":
https://en.wikipedia.org/wiki/MAC_address#Universal_vs._local_(U/L_bit)
>Locally administered addresses are distinguished from universally administered addresses by setting (assigning the value of 1 to) the second-[least-significant bit](https://en.wikipedia.org/wiki/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.[[7]](https://en.wikipedia.org/wiki/MAC_address#cite_note-mac-bit-field-names-8)[[8]](https://en.wikipedia.org/wiki/MAC_address#cite_note-rfc4291-appendix-a-9) If the bit is 0, the address is universally administered, which is why this bit is 0 in all OUIs. 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.
So if I'm reading this correctly, if the first octet of the MAC in binary is `xxxxxx1x`, it's a private (LAA) MAC address. If it's `xxxxxx0x`, it's a public (ULA) MAC address.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Évaluation
Cette issue n'a pas encore été évaluée.