| Network Working Group | J. Abley |
| Internet-Draft | TekSavvy Solutions, Inc. |
| Intended status: Standards Track | April 23, 2013 |
| Expires: October 25, 2013 |
Resource Records for EUI-48 and EUI-64 Addresses in the DNS
draft-jabley-dnsext-eui48-eui64-rrtypes-03
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.
This document defines two new DNS resource record types, EUI48 and EUI64, for encoding ethernet addresses in the DNS.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 25, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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.
The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. This base specification defines many Resource Record (RR) Types, and subsequent specifications have defined others. Each defined RRType provides a means of encoding particular data in the DNS.
48-bit Extended Unique Identifiers (EUI-48) [EUI48] and 64-bit Extended Unique Identifiers (EUI-64) [EUI64] 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The EUI48 RR is used to store a single EUI-48 address in the DNS.
The Type value for the EUI48 RRType is 108 (decimal).
The EUI48 RR is class-independent.
The EUI48 RR has no special Time-to-Live (TTL) requirements.
The RDATA for an EUI48 RR consists of a single, 6-octet EUI48-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EUI48-Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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
The following EUI64 RR stores the EUI-64 address 00-00-5e-ef-10-00-00-2a.
host.example. 86400 IN EUI64 00-00-5e-ef-10-00-00-2a
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.
Cable companies in Canada are required [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.
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.
The specification in this document facilitates a more efficient, consistent and reliable representation of (EUI-48, IP) mapping than was previously available.
The specification of the new RRTYPEs 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 RRTPES should specify how any address conflicts or use of multiple EUI48/EUI64 RRs are handled.
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 "Resource Record (RR) TYPEs" subregistry match the following data:
| Type | Value | Meaning | Reference |
|---|---|---|---|
| EUI48 | 108 | an EUI-48 address | this document |
| EUI64 | 109 | an EUI-64 address | this document |
There may be privacy concerns with publishing EUI addresses in the global DNS. EUI-48 and EUI-64 addresses with the Global bit zero [RFC5342] are intended to represent unique identifiers for network connected equipment notwithstanding many observed cases of duplication due to manufacturing errors, unauthorized use of OUIs, and address spoofing through configuration of network interfaces. Publication of EUI-48 or EUI-64 addresses in the global DNS may result in privacy issues in the form of unique trackable identities.
IP addresses and DNS names for network devices typically change over time but EUI-48 and EUI-64 addresses normally provide a unique identity for a network device. As an example of this, consider a wireless provider that publishes the EUI-48 addresses of its subscribers in the global DNS under the same name as their IP host name. An entity that wants to relate web queries, for example, to a specific customer might, if that customer is using a globally-unique IP address, be able to do a reverse query from the IP address to a DNS name, and then a forward query for the EUI information. If possible, this would enable a tracking entity to relate queries to specific identity regardless of changes in IP addresses and DNS names resulting in a loss of privacy for the subscriber.
These potential concerns can be mitigated through restricting access to zones containing EUI48 or EUI64 RRs or storing such information under a domain name whose construction requires that the querier already know some other permanent identifier.
The author acknowledges the contributions of Olafur Gudmundsson, Mark Smith, Andrew Sullivan, Roy Arends, Michael StJohns and Donald Eastlake III.
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. |
| [RFC1035] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5342] | Eastlake, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008. |
| [EUI48] | IEEE, "Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48)", |
| [EUI64] | IEEE, "Guidelines for use of a 64-bit Extended Unique Identifier (EUI-64)", |
| [NTRE038D] | CRTC Interconnection Steering Committee Network Working Group, "Implementation of IP Address Tracking in DOCSIS Networks (TIF18)", |
This section (and sub-sections) to be removed prior to publication.
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.