Keep an EUI-64 address as eight octets
02EUI64 stores one 64-bit Extended Unique Identifier. It has its own DNS type and field length, rather than being an EUI48 record with optional extra bytes.
Separate fixture places those eight bytes under type 108. That does not make a valid EUI48 Address field. Choose the record type that describes the supplied address; do not silently convert it.
Source for this drawing: RFC 7043 · Read RFC section 4.1 ↗
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.
EUI64 has decimal type 109 and a single eight-octet Address field in network, or big-endian, order.
- EUI64 has decimal type 109 and a single eight-octet Address field in network, or big-endian, order.
- The RFC example is 00-00-5e-ef-10-00-00-2a. Store the supplied address bytes; this RR format specifies no EUI48-to-EUI64 transformation.
- The DNS record encoding does not define Ethernet physical bit-transmission order or alter an existing IP address-resolution process.
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 ↗