idnits 2.17.1 draft-jabley-dnsext-eui48-eui64-rrtypes-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 15, 2013) is 3869 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'X' is mentioned on line 333, but not defined == Missing Reference: 'RFC3597' is mentioned on line 377, but not defined ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft TekSavvy Solutions, Inc. 4 Intended status: Informational August 15, 2013 5 Expires: February 16, 2014 7 Resource Records for EUI-48 and EUI-64 Addresses in the DNS 8 draft-jabley-dnsext-eui48-eui64-rrtypes-07 10 Abstract 12 48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended 13 Unique Identifiers (EUI-64) are address formats specified by the IEEE 14 for use in various layer-2 networks, e.g. Ethernet. 16 This document describes two new DNS resource record types, EUI48 and 17 EUI64, for encoding Ethernet addresses in the DNS. 19 This document describes potentially severe privacy implications 20 resulting from indiscriminate publication of link-layer addresses in 21 the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the 22 public DNS. This document specifies an interoperable encoding of 23 these address types for use in private DNS namespaces, where the 24 privacy concerns can be constrained and mitigated. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 16, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. The EUI48 Resource Record . . . . . . . . . . . . . . . . . . 5 63 3.1. EUI48 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 64 3.2. EUI48 RR Presentation Format . . . . . . . . . . . . . . . 5 65 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. The EUI64 Resource Record . . . . . . . . . . . . . . . . . . 6 67 4.1. EUI64 RDATA Wire Format . . . . . . . . . . . . . . . . . 6 68 4.2. EUI64 RR Presentation Format . . . . . . . . . . . . . . . 6 69 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Example Use-Case: IP Address Tracking in DOCSIS Networks . . . 7 71 6. DNS Protocol Considerations . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 10.3. Informative References . . . . . . . . . . . . . . . . . . 12 79 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . . 13 80 A.1. RRType Parameter Allocation Template . . . . . . . . . . . 13 81 A.2. Change History . . . . . . . . . . . . . . . . . . . . . . 14 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. 87 This base specification defines many Resource Record Types (RRTypes), 88 and subsequent specifications have defined others. Each defined 89 RRType provides a means of encoding particular data in the DNS. 91 48-bit Extended Unique Identifiers (EUI-48) [EUI48] and 64-bit 92 Extended Unique Identifiers (EUI-64) [EUI64] are address formats 93 specified by the IEEE for use in various layer-2 networks, e.g. 94 Ethernet. 96 This document defines two new RRTypes, EUI48 and EUI64 for encoding 97 EUI-48 and EUI-64 addresses in the DNS. 99 There are potentially severe privacy implications resulting from the 100 indiscriminate publication of link-layer addresses in the DNS (see 101 Section 8). This document recommends that EUI-48 or EUI-64 addresses 102 SHOULD NOT be published in the public DNS. This document specifies 103 an interoperable encoding of these address types for use in private 104 DNS namespaces, where the privacy implications can be constrained and 105 mitigated. 107 2. Terminology 109 This document uses capitalised keywords such as MUST and MAY to 110 describe the requirements for using the registered RRTypes. The 111 intended meaning of those keywords in this document are the same as 112 those described in [RFC2119]. Although these keywords are often used 113 to specify normative requirements in IETF Standards, their use in 114 this document does not imply that this document is a standard of any 115 kind. 117 3. The EUI48 Resource Record 119 The EUI48 Resource Record (RR) is used to store a single EUI-48 120 address in the DNS. 122 The Type value for the EUI48 RRType is 108 (decimal). 124 The EUI48 RR is class-independent. 126 The EUI48 RR has no special Time-to-Live (TTL) requirements. 128 3.1. EUI48 RDATA Wire Format 130 The RDATA for an EUI48 RR consists of a single, 6-octet EUI48-Address 131 field, encoded in network (big-endian) order. 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | EUI48-Address | 137 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 3.2. EUI48 RR Presentation Format 143 The Address field MUST be represented as six two-digit hexadecimal 144 numbers separated by hyphens. The hexadecimal digits "A" through "F" 145 MAY be represented in either upper or lower case. 147 3.3. Example 149 The following EUI48 RR stores the EUI-48 unicast address 00-00-5e-00- 150 53-2a. 152 host.example. 86400 IN EUI48 00-00-5e-00-53-2a 154 4. The EUI64 Resource Record 156 The EUI64 RR is used to store a single EUI-64 address in the DNS. 158 The Type value for the EUI64 RR is 109 (decimal). 160 The EUI64 RR is class-independent. 162 The EUI64 RR has no special TTL requirements. 164 4.1. EUI64 RDATA Wire Format 166 The RDATA for an EUI64 RR consists of a single, 8-octet Address 167 field, encoded in network (big-endian) order. 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | EUI-64 Address | 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 4.2. EUI64 RR Presentation Format 178 The Address field MUST be represented as eight two-digit hexadecimal 179 numbers separated by hyphens. The hexadecimal digits "A" through "F" 180 MAY be represented in either upper or lower case. 182 4.3. Example 184 The following EUI64 RR stores the EUI-64 address 00-00-5e-ef-10-00- 185 00-2a. 187 host.example. 86400 IN EUI64 00-00-5e-ef-10-00-00-2a 189 5. Example Use-Case: IP Address Tracking in DOCSIS Networks 191 Canadian cable Internet subscribers are assigned IP addresses using 192 DHCP, using a DHCP server operated by a cable company. In the case 193 where a cable company provides last-mile connectivity to a subscriber 194 on behalf of a third party company (reseller), the DHCP server 195 assigns addresses from a pool supplied by the reseller. The reseller 196 retains knowledge of the EUI-48 address of the DOCSIS modem supplied 197 to the subscriber, but has no direct knowledge of the IP addresses 198 assigned. In order for the reseller to be able to map the IP address 199 assigned to a subscriber to that EUI-48 address (and hence to the 200 subscriber identity), the cable company can make available 201 information from the DHCP server which provides that (EUI-48, IP) 202 address mapping. 204 Cable companies in Canada are required [NTRE038D] to make this 205 address mapping available using the DNS. Zones containing the 206 relevant information are published on DNS servers, access to which is 207 restricted to the resellers corresponding to particular sets of 208 subscribers. Subscriber address information is not published in the 209 public DNS. 211 Existing DNS schemas for the representation of (EUI-48, IP) mapping 212 used by Canadian cable companies are varied and inefficient; in the 213 absence of a RRType for direct encoding of EUI-48 addresses, 214 addresses are variously encoded into owner names or are published in 215 TXT records. 217 The specification in this document facilitates a more efficient, 218 consistent and reliable representation of (EUI-48, IP) mapping than 219 was previously available. 221 6. DNS Protocol Considerations 223 The specification of the new RRTypes in this document has no effect 224 on the address resolution behaviour of any previously existing 225 network processes or protocols. Proposals or specifications to 226 modify or augment address resolution processes or protocols by making 227 use of these RRTypes should specify how any address conflicts or use 228 of multiple EUI48/EUI64 RRs are handled. 230 7. IANA Considerations 232 IANA has assigned the RRType value 108 (decimal) for EUI48 and 109 233 (decimal) for EUI64. This document directs the IANA to confirm that 234 the corresponding entries in the "Resource Record (RR) TYPEs" sub- 235 registry match the following data: 237 +-------+-------+-------------------+---------------+ 238 | Type | Value | Meaning | Reference | 239 +-------+-------+-------------------+---------------+ 240 | EUI48 | 108 | an EUI-48 address | this document | 241 | | | | | 242 | EUI64 | 109 | an EUI-64 address | this document | 243 +-------+-------+-------------------+---------------+ 245 8. Security Considerations 247 There are privacy concerns with the publication of link-layer 248 addresses in the DNS. EUI-48 and EUI-64 addresses with the Local/ 249 Global bit zero [RFC5342] (referred to in [RFC4291] as the universal/ 250 local bit) are intended to represent unique identifiers for network 251 connected equipment, notwithstanding many observed cases of 252 duplication due to manufacturing errors, unauthorised use of OUIs, 253 and address spoofing through configuration of network interfaces. 254 Publication of EUI-48 or EUI-64 addresses in the DNS may result in 255 privacy issues in the form of unique trackable identities that in 256 some cases may be permanent. 258 For example, although IP addresses and DNS names for network devices 259 typically change over time, EUI-48 and EUI-64 addresses configured on 260 the same devices are normally far more stable (in many cases, 261 effectively invariant). Publication of EUI-48 addresses associated 262 with user devices in a way that could be mapped to assigned IP 263 addresses would allow the behaviour of those users to be tracked by 264 third parties, regardless of where and how the user's device is 265 connected to the Internet. This might well result in a loss of 266 privacy for the user. 268 The publication of EUI-48 or EUI-64 addresses associated with 269 deployed equipment, using the mechanism described in this document or 270 any other mechanism, has the potential to facilitate MAC cloning -- 271 that is, facilitate link-layer attacks against deployed devices, e.g. 272 to disrupt service or intercept data. 274 These concerns can be mitigated by restricting access to DNS zones 275 containing EUI48 or EUI64 RRs to specific, authorised clients and by 276 provisioning them in DNS zones that exist in private namespaces only. 278 This document recommends that EUI-48 or EUI-64 addresses SHOULD NOT 279 be published in the public DNS. 281 9. Acknowledgements 283 The author acknowledges the contributions of Olafur Gudmundsson, Mark 284 Smith, Andrew Sullivan, Roy Arends, Michael StJohns, Donald Eastlake 285 III, Randy Bush and John Klensin. 287 10. References 289 10.1. Normative References 291 [EUI48] IEEE, "Guidelines for use of a 48-bit Extended Unique 292 Identifier (EUI-48)". 294 [EUI64] IEEE, "Guidelines for use of a 64-bit Extended Unique 295 Identifier (EUI-64)". 297 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 298 STD 13, RFC 1034, November 1987. 300 [RFC1035] Mockapetris, P., "Domain names - implementation and 301 specification", STD 13, RFC 1035, November 1987. 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, March 1997. 306 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 307 for IEEE 802 Parameters", BCP 141, RFC 5342, 308 September 2008. 310 10.2. Informative References 312 [NTRE038D] 313 CRTC Interconnection Steering Committee Network Working 314 Group, "Implementation of IP Address Tracking in DOCSIS 315 Networks (TIF18)", October 2006. 317 10.3. Informative References 319 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 320 Architecture", RFC 4291, February 2006. 322 Appendix A. Editorial Notes 324 This section (and sub-sections) to be removed prior to publication. 326 A.1. RRType Parameter Allocation Template 328 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE 330 A. Submission Date: 2013-03-18 332 B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE 333 B.2 Kind of RR: [X] Data RR [ ] Meta-RR 335 C. Contact Information for submitter (will be publicly posted): 336 Name: Joe Abley 337 Email Address: jabley@teksavvy.ca 338 International telephone number: +1 519 670 9327 339 Other contact handles: 341 D. Motivation for the new RRTYPE application. 343 The purpose of this RRTYPE application is to allow EUI-48 344 and EUI-64 addresses to be stored in the DNS. EUI-48 345 addresses are those used, for example, in ethernet. 347 E. Description of the proposed RR type. 349 See draft-jabley-dnsext-eui48-eui64-rrtypes for a full 350 description. 352 F. What existing RRTYPE or RRTYPEs come closest to filling that 353 need and why are they unsatisfactory? 355 The TXT record can be used to store arbitrary, unstructured 356 data in the DNS and hence could be used to store EUI-48 and 357 EUI-64 addresses. This approach is unsatisfactory for the 358 usual reasons, i.e. there is no opportunity for validating 359 data before it is stored, and typographical errors must 360 consequently be detected after data retrieval. 362 G. What mnemonic is requested for the new RRTYPE (optional)? 364 EUI48 for EUI-48 addresses; EUI64 for EUI-64 addresses. 366 H. Does the requested RRTYPE make use of any existing IANA 367 registry or require the creation of a new IANA sub-registry 368 in DNS Parameters? If so, please indicate which registry is 369 to be used or created. If a new sub-registry is needed, specify 370 the allocation policy for it and its initial contents. Also 371 include what the modification procedures will be. 373 No. 375 I. Does the proposal require/expect any changes in DNS 376 servers/resolvers that prevent the new type from being processed 377 as an unknown RRTYPE (see [RFC3597])? 379 No. 381 J. Comments: 383 See draft-jabley-dnsext-eui48-eui64-rrtypes for a complete 384 specification. 386 A.2. Change History 388 00 Initial idea, circulated for the purposes of entertainment. 390 01 Presentation format changed from colon-separated to hyphen- 391 separated, to better match conventional usage for big-endian 392 representations of EUI-48 and EUI-64 addresses. IEEE trademarks 393 acknowledged. Code-points assigned by expert review. Other minor 394 tweaks and fixes based on early review. 396 02 Example EUI64 presentation format in text corrected (colons -> 397 hyphens). Examples changed to use to-be-assigned addresses under 398 the IANA OUI. 400 03 Example EUI48 and EUI64 addresses changed to match the guidance in 401 draft-eastlake-5342bis-00. "EUI48" corrected to "EUI64" in the 402 text of Section 4.1. Incorporated suggestions on DNS resolution 403 and privacy considerations from Michael StJohns and Donald 404 Eastlake III. Added example use case relating to Canadian DOCSIS 405 networks. 407 04 Incorporated suggestions from John Klensin. Intended status 408 changed to informational from standards track. Moved examples to 409 a more sensible place. 411 05 Add emphasis that the publication of link-layer addresses in the 412 DNS has potentially severe privacy implications, and is not 413 recommended by this document. Recommend that publication of link- 414 layer addresses in the public DNS should not happen at all. 415 Various wordsmithing for the purposes of clarity. 417 06 Add text regarding MAC cloning in the Security Considerations 418 section. Make text that mentions the "Global bit" more consistent 419 with [RFC5342] and [RFC4291]. 421 07 Make the "SHOULD NOT publish in the public DNS" recommendation 422 stronger. 424 Author's Address 426 Joe Abley 427 TekSavvy Solutions, Inc. 428 470 Moore Street 429 London, ON N6C 2C2 430 Canada 432 Phone: +1 519 670 9327 433 Email: jabley@teksavvy.ca