One document matched: draft-jabley-dnsext-eui48-eui64-rrtypes-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc5342 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5342.xml'>
]>
<rfc category="info" ipr="trust200902"
docName="draft-jabley-dnsext-eui48-eui64-rrtypes-05">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc inline="yes" ?>
<front>
<title abbrev="Resource Records for EUI-48, EUI-64">Resource Records
for EUI-48 and EUI-64 Addresses in the DNS</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization>TekSavvy Solutions, Inc.</organization>
<address>
<postal>
<street>470 Moore Street</street>
<city>London</city>
<region>ON</region>
<code>N6C 2C2</code>
<country>Canada</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>jabley@teksavvy.ca</email>
</address>
</author>
<date day="12" month="June" year="2013"/>
<abstract>
<t>48-bit Extended Unique Identifiers (EUI-48) and 64-bit
Extended Unique Identifiers (EUI-64) are address formats
specified by the IEEE for use in various layer-2 networks,
e.g. Ethernet.</t>
<t>This document describes two new DNS resource record types,
EUI48 and EUI64, for encoding Ethernet addresses in the DNS.</t>
<t>This document describes potentially severe privacy
implications resulting from indiscriminate publication of
link-layer addresses in the DNS. This document recommends
that EUI-48 or EUI-64 addresses SHOULD NOT be published in
the public DNS. This document specifies an interoperable
encoding of these address types for use in private DNS
namespaces, where the privacy concerns can be constrained
and mitigated.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Domain Name System (DNS) is described in <xref
target="RFC1034"/> and <xref target="RFC1035"/>. This base
specification defines many Resource Record Types (RRTypes),
and subsequent specifications have defined others. Each
defined RRType provides a means of encoding particular data
in the DNS.</t>
<t><xref target="EUI48">48-bit Extended Unique Identifiers
(EUI-48)</xref> and <xref target="EUI64">64-bit Extended
Unique Identifiers (EUI-64)</xref> are address formats
specified by the IEEE for use in various layer-2 networks,
e.g. Ethernet.</t>
<t>This document defines two new RRTypes, EUI48 and EUI64
for encoding EUI-48 and EUI-64 addresses in the DNS.</t>
<t>There are potentially severe privacy implications resulting
from the indiscriminate publication of link-layer addresses
in the DNS (see <xref target="security"/>). This document
recommends that EUI-48 or EUI-64 addresses SHOULD NOT be
published in the public DNS. This document specifies an
interoperable encoding of these address types for use in
private DNS namespaces, where the privacy implications can
be constrained and mitigated.</t>
</section>
<section title="Terminology">
<t>This document uses capitalised keywords such as MUST and
MAY to describe the requirements for using the registered
RRTypes. The intended meaning of those keywords in this
document are the same as those described in <xref
target="RFC2119"/>. Although these keywords are often used
to specify normative requirements in IETF Standards, their
use in this document does not imply that this document is
a standard of any kind.</t>
</section>
<section title="The EUI48 Resource Record">
<t>The EUI48 Resource Record (RR) is used to store a single
EUI-48 address in the DNS.</t>
<t>The Type value for the EUI48 RRType is 108 (decimal).</t>
<t>The EUI48 RR is class-independent.</t>
<t>The EUI48 RR has no special Time-to-Live (TTL) requirements.</t>
<section title="EUI48 RDATA Wire Format">
<t>The RDATA for an EUI48 RR consists of a single, 6-octet
EUI48-Address field, encoded in network (big-endian) order.</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EUI48-Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section title="EUI48 RR Presentation Format" anchor="eui48pres">
<t>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.</t>
</section>
<section title="Example">
<t>The following EUI48 RR stores the EUI-48 unicast address
00-00-5e-00-53-2a.</t>
<figure>
<artwork>
host.example. 86400 IN EUI48 00-00-5e-00-53-2a
</artwork>
</figure>
</section>
</section>
<section title="The EUI64 Resource Record" anchor="eui64rr">
<t>The EUI64 RR is used to store a single EUI-64 address in the DNS.</t>
<t>The Type value for the EUI64 RR is 109 (decimal).</t>
<t>The EUI64 RR is class-independent.</t>
<t>The EUI64 RR has no special TTL requirements.</t>
<section title="EUI64 RDATA Wire Format" anchor="eui64wire">
<t>The RDATA for an EUI64 RR consists of a single, 8-octet
Address field, encoded in network (big-endian) order.</t>
<figure>
<artwork>
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section title="EUI64 RR Presentation Format" anchor="eui64pres">
<t>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.</t>
</section>
<section title="Example">
<t>The following EUI64 RR stores the EUI-64 address
00-00-5e-ef-10-00-00-2a.</t>
<figure>
<artwork>
host.example. 86400 IN EUI64 00-00-5e-ef-10-00-00-2a
</artwork>
</figure>
</section>
</section>
<section title="Example Use-Case: IP Address Tracking in DOCSIS Networks">
<t>Canadian cable Internet subscribers are assigned IP
addresses using DHCP, using a DHCP server operated by a
cable company. In the case where a cable company provides
last-mile connectivity to a subscriber on behalf of a third
party company (reseller), the DHCP server assigns addresses
from a pool supplied by the reseller. The reseller retains
knowledge of the EUI-48 address of the DOCSIS modem supplied
to the subscriber, but has no direct knowledge of the IP
addresses assigned. In order for the reseller to be able
to map the IP address assigned to a subscriber to that
EUI-48 address (and hence to the subscriber identity), the
cable company can make available information from the DHCP
server which provides that (EUI-48, IP) address mapping.</t>
<t>Cable companies in Canada are required <xref target="NTRE038D"/>
to make this address mapping available using the DNS. Zones
containing the relevant information are published on DNS
servers, access to which is restricted to the resellers
corresponding to particular sets of subscribers. Subscriber
address information is not published in the public DNS.</t>
<t>Existing DNS schemas for the representation of (EUI-48,
IP) mapping used by Canadian cable companies are varied and
inefficient; in the absence of a RRType for direct encoding
of EUI-48 addresses, addresses are variously encoded into
owner names or are published in TXT records.</t>
<t>The specification in this document facilitates a more
efficient, consistent and reliable representation of (EUI-48,
IP) mapping than was previously available.</t>
</section>
<section title="DNS Protocol Considerations">
<t>The specification of the new RRTypes in this document has
no effect on the address resolution behaviour of any previously
existing network processes or protocols. Proposals or
specifications to modify or augment address resolution
processes or protocols by making use of these RRTypes should
specify how any address conflicts or use of multiple
EUI48/EUI64 RRs are handled.</t>
</section>
<section title="IANA Considerations">
<t>IANA has assigned the RRType value 108 (decimal) for EUI48
and 109 (decimal) for EUI64. This document directs the IANA
to confirm that the corresponding entries in the <eref
target="http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-3">"Resource
Record (RR) TYPEs" sub-registry</eref> match the following
data:</t>
<texttable>
<ttcol>Type</ttcol>
<ttcol>Value</ttcol>
<ttcol>Meaning</ttcol>
<ttcol>Reference</ttcol>
<c>EUI48</c>
<c>108</c>
<c>an EUI-48 address</c>
<c>this document</c>
<c>EUI64</c>
<c>109</c>
<c>an EUI-64 address</c>
<c>this document</c>
</texttable>
</section>
<section title="Security Considerations" anchor="security">
<t>There are privacy concerns with the publication of link-layer
addresses in the DNS. EUI-48 and EUI-64 addresses with the
Global bit zero <xref target="RFC5342"/> are intended to
represent unique identifiers for network connected equipment
(notwithstanding many observed cases of duplication due to
manufacturing errors, unauthorised use of OUIs, and address
spoofing through configuration of network interfaces).
Publication of EUI-48 or EUI-64 addresses in the DNS may
result in privacy issues in the form of unique trackable
identities.</t>
<t>For example, although IP addresses and DNS names for network
devices typically change over time, EUI-48 and EUI-64
addresses configured on the same devices are normally far
more stable (in many cases, effectively invariant).
Publication of EUI-48 addresses associated with user devices
in a way that could be mapped to assigned IP addresses would
allow the behaviour of those users to be tracked by third
parties, regardless of where and how the user's device is
connected to the Internet. This might well result in a loss
of privacy for the user.</t>
<t>These concerns can be mitigated by restricting access to
DNS zones containing EUI48 or EUI64 RRs to specific,
authorised clients and by provisioning them in DNS zones
that exist in private namespaces only.</t>
<t>This document recommends that EUI-48 or EUI-64 addresses
SHOULD NOT be published in the public DNS.</t>
</section>
<section title="Acknowledgements">
<t>The author acknowledges the contributions of Olafur
Gudmundsson, Mark Smith, Andrew Sullivan, Roy Arends, Michael
StJohns, Donald Eastlake III, Randy Bush and John Klensin.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1034;
&rfc1035;
&rfc2119;
&rfc5342;
<reference anchor="EUI48">
<front>
<title>Guidelines for use of a 48-bit Extended Unique
Identifier (EUI-48)</title>
<author>
<organization>IEEE</organization>
<address/>
</author>
</front>
<format type="PDF" target="http://standards.ieee.org/develop/regauth/tut/eui48.pdf"/>
</reference>
<reference anchor="EUI64">
<front>
<title>Guidelines for use of a 64-bit Extended Unique
Identifier (EUI-64)</title>
<author>
<organization>IEEE</organization>
<address/>
</author>
</front>
<format type="PDF" target="http://standards.ieee.org/develop/regauth/tut/eui64.pdf"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="NTRE038D">
<front>
<title>Implementation of IP Address Tracking in DOCSIS Networks
(TIF18)</title>
<author>
<organization>CRTC Interconnection Steering Committee
Network Working Group</organization>
<address/>
</author>
<date day="17" month="October" year="2006"/>
</front>
<format type="DOC" target="http://www.crtc.gc.ca/public/cisc/nt/NTRE038D.doc"/>
</reference>
</references>
<section title="Editorial Notes">
<t>This section (and sub-sections) to be removed prior to
publication.</t>
<section title="RRType Parameter Allocation Template">
<figure>
<artwork>
DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
A. Submission Date: 2013-03-18
B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE
B.2 Kind of RR: [X] Data RR [ ] Meta-RR
C. Contact Information for submitter (will be publicly posted):
Name: Joe Abley
Email Address: jabley@teksavvy.ca
International telephone number: +1 519 670 9327
Other contact handles:
D. Motivation for the new RRTYPE application.
The purpose of this RRTYPE application is to allow EUI-48
and EUI-64 addresses to be stored in the DNS. EUI-48
addresses are those used, for example, in ethernet.
E. Description of the proposed RR type.
See draft-jabley-dnsext-eui48-eui64-rrtypes for a full
description.
F. What existing RRTYPE or RRTYPEs come closest to filling that
need and why are they unsatisfactory?
The TXT record can be used to store arbitrary, unstructured
data in the DNS and hence could be used to store EUI-48 and
EUI-64 addresses. This approach is unsatisfactory for the
usual reasons, i.e. there is no opportunity for validating
data before it is stored, and typographical errors must
consequently be detected after data retrieval.
G. What mnemonic is requested for the new RRTYPE (optional)?
EUI48 for EUI-48 addresses; EUI64 for EUI-64 addresses.
H. Does the requested RRTYPE make use of any existing IANA
registry or require the creation of a new IANA sub-registry
in DNS Parameters? If so, please indicate which registry is
to be used or created. If a new sub-registry is needed, specify
the allocation policy for it and its initial contents. Also
include what the modification procedures will be.
No.
I. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being processed
as an unknown RRTYPE (see [RFC3597])?
No.
J. Comments:
See draft-jabley-dnsext-eui48-eui64-rrtypes for a complete
specification.
</artwork>
</figure>
</section>
<section title="Change History">
<t>
<list style="hanging">
<t hangText="00">Initial idea, circulated for the purposes of
entertainment.</t>
<t hangText="01">Presentation format changed from
colon-separated to hyphen-separated, to better match
conventional usage for big-endian representations of
EUI-48 and EUI-64 addresses. IEEE trademarks acknowledged.
Code-points assigned by expert review. Other minor
tweaks and fixes based on early review.</t>
<t hangText="02">Example EUI64 presentation format in text
corrected (colons -> hyphens). Examples changed to use
to-be-assigned addresses under the IANA OUI.</t>
<t hangText="03">Example EUI48 and EUI64 addresses changed
to match the guidance in draft-eastlake-5342bis-00.
"EUI48" corrected to "EUI64" in the text of <xref
target="eui64wire"/>. Incorporated suggestions on
DNS resolution and privacy considerations from
Michael StJohns and Donald Eastlake III. Added example
use case relating to Canadian DOCSIS networks.</t>
<t hangText="04">Incorporated suggestions from John
Klensin. Intended status changed to informational
from standards track. Moved examples to a more sensible
place.</t>
<t hangText="05">Add emphasis that the publication of
link-layer addresses in the DNS has potentially severe
privacy implications, and is not recommended by this
document. Recommend that publication of link-layer
addresses in the public DNS should not happen at all.
Various wordsmithing for the purposes of clarity.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:02 |