1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 7043 Dyn, Inc.
Category: Informational October 2013
ISSN: 2070-1721
<span class="h1">Resource Records for EUI-48 and EUI-64 Addresses in the DNS</span>
Abstract
48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended Unique
Identifier (EUI-64) are address formats specified by the IEEE for use
in various layer-2 networks, e.g., Ethernet.
This document describes two new DNS resource record types, EUI48 and
EUI64, for encoding Ethernet addresses in the DNS.
This document describes potentially severe privacy implications
resulting from indiscriminate publication of link-layer addresses in
the DNS. 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.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7043">http://www.rfc-editor.org/info/rfc7043</a>.
<span class="grey">Abley Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7043">RFC 7043</a> Resource Records for EUI-48, EUI-64 October 2013</span>
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. The EUI48 Resource Record . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. EUI48 RDATA Wire Format . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. EUI48 RR Presentation Format . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.3">3.3</a>. Example . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. The EUI64 Resource Record . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. EUI64 RDATA Wire Format . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. EUI64 RR Presentation Format . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. Example . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Example Use Case: IP Address Tracking in DOCSIS Networks . . <a href="#page-5">5</a>
<a href="#section-6">6</a>. DNS Protocol Considerations . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-9">9</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<span class="grey">Abley Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7043">RFC 7043</a> Resource Records for EUI-48, EUI-64 October 2013</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Domain Name System (DNS) is described in [<a href="./rfc1034" title=""Domain names - concepts and facilities"">RFC1034</a>] and [<a href="./rfc1035" title=""Domain names - implementation and specification"">RFC1035</a>].
This base specification defines many resource record (RR) types, and
subsequent specifications have defined others. Each defined RR type
provides a means of encoding particular data in the DNS.
48-bit Extended Unique Identifier (EUI-48) [<a href="#ref-EUI48" title=""Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48)"">EUI48</a>] and 64-bit
Extended Unique Identifier (EUI-64) [<a href="#ref-EUI64" title=""Guidelines for 64-bit Global Identifier (EUI-64)"">EUI64</a>] are address formats
specified by the IEEE for use in various layer-2 networks, e.g.,
Ethernet.
This document defines two new RR types, EUI48 and EUI64, for encoding
EUI-48 and EUI-64 addresses in the DNS.
There are potentially severe privacy implications resulting from the
indiscriminate publication of link-layer addresses in the DNS (see
<a href="#section-8">Section 8</a>). 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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
This document uses capitalized keywords such as MUST and MAY to
describe the requirements for using the registered RR types. The
intended meaning of those keywords in this document are the same as
those described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>]. 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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The EUI48 Resource Record</span>
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.
<span class="grey">Abley Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7043">RFC 7043</a> Resource Records for EUI-48, EUI-64 October 2013</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. EUI48 RDATA Wire Format</span>
The RDATA for an EUI48 RR consists of 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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. EUI48 RR Presentation Format</span>
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.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Example</span>
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
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. The EUI64 Resource Record</span>
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.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. EUI64 RDATA Wire Format</span>
The RDATA for an EUI64 RR consists of 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Abley Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7043">RFC 7043</a> Resource Records for EUI-48, EUI-64 October 2013</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. EUI64 RR Presentation Format</span>
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.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Example</span>
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
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Example Use Case: IP Address Tracking in DOCSIS Networks</span>
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 that provides (EUI-48, IP) address
mapping.
Cable companies in Canada are required [<a href="#ref-NTRE038D">NTRE038D</a>] 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.
Existing DNS schemas for the representation of (EUI-48, IP) mapping
used by Canadian cable companies are varied and inefficient; in the
absence of an RR type for direct encoding of EUI-48 addresses,
addresses are variously encoded into owner names or are published in
TXT records.
The specification in this document facilitates a more efficient,
consistent, and reliable representation of (EUI-48, IP) mapping than
was previously available.
<span class="grey">Abley Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7043">RFC 7043</a> Resource Records for EUI-48, EUI-64 October 2013</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. DNS Protocol Considerations</span>
The specification of the new RR types in this document has no effect
on the address resolution behavior 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 RR types should specify how any address conflicts or use of
multiple EUI48/EUI64 RRs are handled.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has assigned the RR type value 108 (decimal) for EUI48 and 109
(decimal) for EUI64. The corresponding entries in the "Resource
Record (RR) TYPEs" subregistry (<a href="http://www.iana.org/assignments/dns-parameters/">http://www.iana.org/assignments/</a>
<a href="http://www.iana.org/assignments/dns-parameters/">dns-parameters/</a>) match the following data:
+-------+-------+-------------------+---------------+
| Type | Value | Meaning | Reference |
+-------+-------+-------------------+---------------+
| EUI48 | 108 | an EUI-48 address | this document |
| EUI64 | 109 | an EUI-64 address | this document |
+-------+-------+-------------------+---------------+
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
There are privacy concerns with the publication of link-layer
addresses in the DNS. EUI-48 and EUI-64 addresses with the
Local/Global bit zero [<a href="./rfc7042" title=""IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters"">RFC7042</a>] (referred to in [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>] as the
universal/local bit) are intended to represent unique identifiers for
network connected equipment, notwithstanding many observed cases of
duplication due to manufacturing errors, unauthorized use of
Organizationally Unique Identifiers (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 that in some cases may be
permanent.
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 behavior 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.
<span class="grey">Abley Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7043">RFC 7043</a> Resource Records for EUI-48, EUI-64 October 2013</span>
The publication of EUI-48 or EUI-64 addresses associated with
deployed equipment, using the mechanism described in this document or
any other mechanism, has the potential to facilitate Media Access
Control (MAC) cloning -- that is, facilitate link-layer attacks
against deployed devices, e.g., to disrupt service or intercept 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 exist in private namespaces only.
This document recommends that EUI-48 or EUI-64 addresses SHOULD NOT
be published in the public DNS.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The author acknowledges the contributions of Olafur Gudmundsson, Mark
Smith, Andrew Sullivan, Roy Arends, Michael StJohns, Donald Eastlake
III, Randy Bush, and John Klensin.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-EUI48">EUI48</a>] IEEE, "Guidelines for use of a 48-bit Extended Unique
Identifier (EUI-48)",
<<a href="http://standards.ieee.org/develop/regauth/tut/eui48.pdf">http://standards.ieee.org/develop/regauth/tut/eui48.pdf</a>>.
[<a id="ref-EUI64">EUI64</a>] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)",
November 2012,
<<a href="http://standards.ieee.org/develop/regauth/tut/eui64.pdf">http://standards.ieee.org/develop/regauth/tut/eui64.pdf</a>>.
[<a id="ref-RFC1034">RFC1034</a>] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, <a href="./rfc1034">RFC 1034</a>, November 1987.
[<a id="ref-RFC1035">RFC1035</a>] Mockapetris, P., "Domain names - implementation and
specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC7042">RFC7042</a>] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802
Parameters", <a href="https://www.rfc-editor.org/bcp/bcp141">BCP 141</a>, <a href="./rfc7042">RFC 7042</a>, October 2013.
<span class="grey">Abley Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7043">RFC 7043</a> Resource Records for EUI-48, EUI-64 October 2013</span>
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-NTRE038D">NTRE038D</a>]
CRTC Interconnection Steering Committee (CISC) Network
Working Group, "Implementation of IP Address Tracking in
DOCSIS Networks (TIF18)", NTRE038D Consensus Report,
October 2006,
<<a href="http://www.crtc.gc.ca/public/cisc/nt/NTRE038D.doc">http://www.crtc.gc.ca/public/cisc/nt/NTRE038D.doc</a>>.
[<a id="ref-RFC4291">RFC4291</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc4291">RFC 4291</a>, 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
Abley Informational [Page 8]
</pre>
|
