summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7043.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7043.txt')
-rw-r--r--doc/rfc/rfc7043.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc7043.txt b/doc/rfc/rfc7043.txt
new file mode 100644
index 0000000..e6a666e
--- /dev/null
+++ b/doc/rfc/rfc7043.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Abley
+Request for Comments: 7043 Dyn, Inc.
+Category: Informational October 2013
+ISSN: 2070-1721
+
+
+ Resource Records for EUI-48 and EUI-64 Addresses in the DNS
+
+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 Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7043.
+
+
+
+
+
+
+
+
+
+
+
+
+Abley Informational [Page 1]
+
+RFC 7043 Resource Records for EUI-48, EUI-64 October 2013
+
+
+Copyright Notice
+
+ 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.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley Informational [Page 2]
+
+RFC 7043 Resource Records for EUI-48, EUI-64 October 2013
+
+
+1. Introduction
+
+ 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 RR type
+ provides a means of encoding particular data in the DNS.
+
+ 48-bit Extended Unique Identifier (EUI-48) [EUI48] and 64-bit
+ Extended Unique Identifier (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.
+
+ There are potentially severe privacy implications resulting from the
+ indiscriminate publication of link-layer addresses in the DNS (see
+ Section 8). 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.
+
+2. Terminology
+
+ 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 [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.
+
+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.
+
+
+
+
+
+
+
+
+Abley Informational [Page 3]
+
+RFC 7043 Resource Records for EUI-48, EUI-64 October 2013
+
+
+3.1. EUI48 RDATA Wire Format
+
+ 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 |
+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+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.
+
+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 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 |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Abley Informational [Page 4]
+
+RFC 7043 Resource Records for EUI-48, EUI-64 October 2013
+
+
+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
+
+ 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 [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.
+
+ 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.
+
+
+
+
+
+
+
+Abley Informational [Page 5]
+
+RFC 7043 Resource Records for EUI-48, EUI-64 October 2013
+
+
+6. DNS Protocol Considerations
+
+ 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.
+
+7. IANA Considerations
+
+ 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 (http://www.iana.org/assignments/
+ dns-parameters/) match 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
+
+ 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 [RFC7042] (referred to in [RFC4291] 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.
+
+
+
+
+
+Abley Informational [Page 6]
+
+RFC 7043 Resource Records for EUI-48, EUI-64 October 2013
+
+
+ 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.
+
+9. Acknowledgements
+
+ The author acknowledges the contributions of Olafur Gudmundsson, Mark
+ Smith, Andrew Sullivan, Roy Arends, Michael StJohns, Donald Eastlake
+ III, Randy Bush, and John Klensin.
+
+10. References
+
+10.1. Normative References
+
+ [EUI48] IEEE, "Guidelines for use of a 48-bit Extended Unique
+ Identifier (EUI-48)",
+ <http://standards.ieee.org/develop/regauth/tut/eui48.pdf>.
+
+ [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)",
+ November 2012,
+ <http://standards.ieee.org/develop/regauth/tut/eui64.pdf>.
+
+ [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.
+
+ [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
+ IETF Protocol and Documentation Usage for IEEE 802
+ Parameters", BCP 141, RFC 7042, October 2013.
+
+
+
+
+
+
+
+
+Abley Informational [Page 7]
+
+RFC 7043 Resource Records for EUI-48, EUI-64 October 2013
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley Informational [Page 8]
+