Keep ordinary address resolution unchanged
04These records carry address data to applications that choose to read them. Defining a new RR type does not rewrite existing address-resolution protocols.
Separate fixture has two EUI48 records, each with its own single address. The application has no specified conflict-selection policy, so this illustration stops before choosing an address. The RFC supplies no first-record-wins rule.
Source for this drawing: RFC 7043 · Read RFC section 6 ↗
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.
Both RR types are class independent and have no special TTL requirements (§§3–4). Ordinary DNS class and TTL rules remain separate from the Address field.
- Both RR types are class independent and have no special TTL requirements (§§3–4). Ordinary DNS class and TTL rules remain separate from the Address field.
- §6 says the new types have no effect on the address-resolution behavior of previously existing processes or protocols.
- Proposals that use these records to change address resolution should specify conflicts and multiple-record handling. The RFC does not define an automatic winner or a new ARP/neighbor-discovery procedure.
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 ↗