RFC 7043

Resource Records for EUI-48 and EUI-64 Addresses in the DNS

📅 published October 2013, from ietf

Request for Comments: 7043 💖

Resource Records for EUI-48 and EUI-64 Addresses in the DNS ✨

  • Series: Internet Engineering Task Force (IETF) 🌸
  • Author: J. Abley, Dyn, Inc. 💅
  • Category: Informational 📚
  • Date: October 2013 🗓️
  • ISSN: 2070-1721
  • Obsoletes / Updates: none listed in the title block 🦋

Abstract ✨

okay so, EUI-48 and EUI-64 are address formats the IEEE specifies for use in various layer-2 networks, e.g., Ethernet 🔌

this doc defines two new DNS resource record types, EUI48 and EUI64, for encoding Ethernet addresses in the DNS 🎀

⚠️ there are potentially severe privacy implications from publishing link-layer addresses in the DNS indiscriminately 😭 so EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. this doc specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated 🔒

Status of This Memo 🧚

this is not an Internet Standards Track specification. it's published for informational purposes 📚

this doc is a product of the IETF 💖 it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 👀

for info on the current status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc7043 🌈

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🔐

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read those carefully, bestie, because they spell out your rights and restrictions for this doc 📜 code components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  The EUI48 Resource Record . . . . . . . . . . . . . . . . . .   3
  3.1.  EUI48 RDATA Wire Format . . . . . . . . . . . . . . . . .   4
  3.2.  EUI48 RR Presentation Format  . . . . . . . . . . . . . .   4
  3.3.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  The EUI64 Resource Record . . . . . . . . . . . . . . . . . .   4
  4.1.  EUI64 RDATA Wire Format . . . . . . . . . . . . . . . . .   4
  4.2.  EUI64 RR Presentation Format  . . . . . . . . . . . . . .   5
  4.3.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   5
5.  Example Use Case: IP Address Tracking in DOCSIS Networks  . .   5
6.  DNS Protocol Considerations . . . . . . . . . . . . . . . . .   6
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
  10.2.  Informative References . . . . . . . . . . . . . . . . .   8

1. Introduction 🌟

the DNS is described in [RFC1034] and [RFC1035] 📖 the base spec defines lots of resource record (RR) types, and later specs have defined others. each defined RR type gives you a way to encode particular data in the DNS 💅

EUI-48 [EUI48] and EUI-64 [EUI64] are address formats the IEEE specifies for use in various layer-2 networks, e.g., Ethernet 🔌

this doc defines two new RR types, EUI48 and EUI64, for encoding EUI-48 and EUI-64 addresses in the DNS 🎀

⚠️ the indiscriminate publication of link-layer addresses in the DNS has potentially severe privacy implications (see Section 8) 😭 this doc recommends that EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. it specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy implications can be constrained and mitigated 🔒

2. Terminology 🧠

this doc uses capitalized keywords such as MUST and MAY to describe the requirements for using the registered RR types 💖 what those keywords mean here is the same as what's described in [RFC2119] 📝 even though these keywords are often used to specify normative requirements in IETF Standards, using them here doesn't mean this doc is a standard of any kind 🙈

3. The EUI48 Resource Record 🦋

the EUI48 resource record (RR) is used to store a single EUI-48 address in the DNS 💜

the Type value for the EUI48 RR is 108 (decimal) 🔢

the EUI48 RR is class independent 🌈

the EUI48 RR has no special Time-to-Live (TTL) requirements ⏰

3.1. EUI48 RDATA Wire Format 🍓

the RDATA for an EUI48 RR is a single, 6-octet Address field, encoded in network (big-endian) order 🧚

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          EUI-48 Address                       |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2. EUI48 RR Presentation Format 🎀

the Address field MUST be represented as six two-digit hexadecimal numbers separated by hyphens 🫶 the hexadecimal digits "A" through "F" MAY be represented in either upper or lower case, so do your thing 💅

3.3. Example ✨

the following EUI48 RR stores the EUI-48 unicast address 00-00-5e-00-53-2a 🦋

  host.example. 86400 IN EUI48 00-00-5e-00-53-2a

4. The EUI64 Resource Record 💜

the EUI64 RR is used to store a single EUI-64 address in the DNS 🌸

the Type value for the EUI64 RR is 109 (decimal) 🔢

the EUI64 RR is class independent 🌈

the EUI64 RR has no special TTL requirements ⏰

4.1. EUI64 RDATA Wire Format 🍓

the RDATA for an EUI64 RR is a single, 8-octet Address field, encoded in network (big-endian) order 🧚

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          EUI-64 Address                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2. EUI64 RR Presentation Format 🎀

the Address field MUST be represented as eight two-digit hexadecimal numbers separated by hyphens 🫶 the hexadecimal digits "A" through "F" MAY be represented in either upper or lower case 💅

4.3. Example ✨

the following EUI64 RR stores the EUI-64 unicast address 00-00-5e-ef-10-00-00-2a 🦋

  host.example. 86400 IN EUI64 00-00-5e-ef-10-00-00-2a

5. Example Use Case: IP Address Tracking in DOCSIS Networks 🇨🇦

okay this one is so iconic 😭 Canadian cable Internet subscribers get their IP addresses through DHCP, from a DHCP server run by a cable company 🌐 when a cable company provides last-mile connectivity to a subscriber on behalf of a third-party company (a reseller), the DHCP server hands out addresses from a pool the reseller supplied 🧺 the reseller knows the EUI-48 address of the DOCSIS modem it gave the subscriber, but it has no direct knowledge of the IP addresses assigned 🙃 so for the reseller to map the assigned IP address to that EUI-48 address (and therefore to the subscriber's identity), the cable company can make (EUI-48, IP) address mapping info from the DHCP server available 💖

Cable companies in Canada are required [NTRE038D] to make this address mapping available using the DNS 📡 the zones with the relevant info get published on DNS servers, and access is restricted to the resellers for particular sets of subscribers 🔐 subscriber address info is not published in the public DNS 🙌

right now, the DNS schemas for representing (EUI-48, IP) mappings used by Canadian cable companies are all over the place and inefficient 😵‍💫 without an RR type for directly encoding EUI-48 addresses, the addresses get encoded into owner names or published in TXT records instead 🤷‍♀️

this spec makes for a more efficient, consistent, and reliable representation of (EUI-48, IP) mapping than was available before 👑

6. DNS Protocol Considerations 🧩

the new RR types in this doc have no effect on the address resolution behavior of any previously existing network processes or protocols 🙌 proposals or specs that modify or augment address resolution processes or protocols by using these RR types should specify how any address conflicts or use of multiple EUI48/EUI64 RRs are handled 📝

7. IANA Considerations 🌸

IANA has assigned RR type value 108 (decimal) for EUI48 and 109 (decimal) for EUI64 🎉 the matching entries in the "Resource Record (RR) TYPEs" subregistry (http://www.iana.org/assignments/dns-parameters/) hold the following data:

          +-------+-------+-------------------+---------------+
          | Type  | Value | Meaning           | Reference     |
          +-------+-------+-------------------+---------------+
          | EUI48 | 108   | an EUI-48 address | this document |
          | EUI64 | 109   | an EUI-64 address | this document |
          +-------+-------+-------------------+---------------+

8. Security Considerations 🔒✨

okay bestie, this section is the serious one, so we're keeping the drama but also keeping it real 💅. there are privacy concerns with putting link-layer addresses in the DNS 😭. EUI-48 and EUI-64 addresses with the Local/Global bit zero [RFC7042] (which [RFC4291] calls the universal/local bit) are meant to be unique identifiers for network connected equipment 🦋. BUT ngl there are loads of observed cases of duplicates, because of manufacturing errors, unauthorized use of Organizationally Unique Identifiers (OUIs), and address spoofing through configuration of network interfaces 💀. so the uniqueness is more of a vibe than a guarantee 🙈.

publishing EUI-48 or EUI-64 addresses in the DNS may lead to privacy issues in the form of unique trackable identities 🕵️‍♀️. in some cases these identities may be permanent, which is lowkey terrifying 😭.

for example, IP addresses and DNS names for network devices typically change over time 🌸. but the EUI-48 and EUI-64 addresses configured on the same devices are normally way more stable (in many cases, effectively invariant) 💎. so if EUI-48 addresses for user devices got published in a way that could be mapped to assigned IP addresses, third parties could track what those users are doing 👀. that doesn't care where or how the user's device connects to the Internet either 🌍. this might totally result in a loss of privacy for the user 💔.

the publication of EUI-48 or EUI-64 addresses for deployed equipment, using the mechanism in this document or any other mechanism, has the potential to make Media Access Control (MAC) cloning easier. that means link-layer attacks against deployed devices, like disrupting service or intercepting data 🚨.

these concerns can be mitigated by restricting access to DNS zones containing EUI48 or EUI64 RRs to specific, authorized clients, and by provisioning them in DNS zones that only exist in private namespaces 🔐.

this document recommends that EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS 🙅‍♀️. so yeah, keep those addresses off the public internet, periodt 💅🫶.

9. Acknowledgements 🎀

the author would like to thank Olafur Gudmundsson, Mark Smith, Andrew Sullivan, Roy Arends, Michael StJohns, Donald Eastlake III, Randy Bush, and John Klensin 🌈 for their contributions. iconic squad 👑.

10. References 📚

10.1. Normative References 🧚

10.2. Informative References 🌸

  • [NTRE038D] CRTC Interconnection Steering Committee (CISC) Network Working Group, "Implementation of IP Address Tracking in DOCSIS Networks (TIF18)", NTRE038D Consensus Report, October 2006, <http://www.crtc.gc.ca/public/cisc/nt/NTRE038D.doc>.
  • [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

Author's Address 💌

Joe Abley Dyn, Inc. 470 Moore Street London, ON N6C 2C2 Canada

Phone: +1 519 670 9327 EMail: jabley@dyn.com

📦 where this page comes from