Constrain tracking and address-cloning exposure
06A stable link-layer address can link changing IP addresses or names over time. Readable address data is not proof of a device’s identity or permission to track its user.
Separate permitted fixture has both a private DNS view and an authorized client. Both gates pass before disclosure. These restrictions mitigate exposure; they do not by themselves encrypt DNS, guarantee anonymity or verify the address’s truth.
Source for this drawing: RFC 7043 · Read RFC section 8 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The RFC recommends that EUI-48 and EUI-64 addresses SHOULD NOT be published in public DNS. This is a recommendation, not an invented universal MUST NOT.
- The RFC recommends that EUI-48 and EUI-64 addresses SHOULD NOT be published in public DNS. This is a recommendation, not an invented universal MUST NOT.
- Addresses with Local/Global bit zero are intended as globally unique identifiers, but the RFC notes manufacturing duplication, unauthorized OUI use and configurable spoofing. Publication can expose trackable identities and facilitate MAC cloning.
- Private namespaces together with access restricted to specific authorized clients can mitigate these concerns. A private-looking name alone supplies neither access control nor automatic encryption.
Fictional offline examples only. EUI records carry supplied address data; they do not authenticate devices, implement IP resolution or authorize tracking. RFC7043 is Informational. The application policies shown are explicitly chosen fixtures.
Read the RFC section ↗