diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml
index fad5a5f2be..141ddedcc0 100644
--- a/doc/arm/Bv9ARM-book.xml
+++ b/doc/arm/Bv9ARM-book.xml
@@ -13146,6 +13146,58 @@ view external {
+
+
+
+ ATMA
+
+
+
+
+ ATM Address.
+
+
+
+
+
+
+ CAA
+
+
+
+
+ Identifies which Certificate Authorities can issues
+ certificates for this domain and what rules they
+ need to follow when doing so. Defined in RFC 6844.
+
+
+
+
+
+
+ CDNSKEY
+
+
+
+
+ Identifies which DNSKEY records should be published
+ as DS records in the parent zone.
+
+
+
+
+
+
+ CDS
+
+
+
+
+ Contains the set of DS records that should be published
+ by the parent zone.
+
+
+
@@ -13185,6 +13237,20 @@ view external {
+
+
+
+ DLV
+
+
+
+
+ A DNS Look-aside Validation record which contains
+ the records that are used as trust anchors for
+ zones in a DLV namespace. Described in RFC 4431.
+
+
+
@@ -13229,6 +13295,54 @@ view external {
+
+
+
+ EID
+
+
+
+
+ End Point Identifier.
+
+
+
+
+
+
+ EUI48
+
+
+
+
+ A 48-bit EUI address. Described in RFC 7043.
+
+
+
+
+
+
+ EUI64
+
+
+
+
+ A 64-bit EUI address. Described in RFC 7043.
+
+
+
+
+
+
+ GID
+
+
+
+
+ Reserved.
+
+
+
@@ -13254,6 +13368,19 @@ view external {
+
+
+
+ HIP
+
+
+
+
+ Host Identity Protocol Address.
+ Described in RFC 5205.
+
+
+
@@ -13308,6 +13435,34 @@ view external {
+
+
+
+ L32
+
+
+
+
+ Holds 32-bit Locator values for
+ Identifier-Locator Network Protocol. Described
+ in RFC 6742.
+
+
+
+
+
+
+ L64
+
+
+
+
+ Holds 64-bit Locator values for
+ Identifier-Locator Network Protocol. Described
+ in RFC 6742.
+
+
+
@@ -13321,6 +13476,91 @@ view external {
+
+
+
+ LP
+
+
+
+
+ Identifier-Locator Network Protocol.
+ Described in RFC 6742.
+
+
+
+
+
+
+ MB
+
+
+
+
+ Mail Box. Historical.
+
+
+
+
+
+
+ MD
+
+
+
+
+ Mail Destination. Historical.
+
+
+
+
+
+
+ MF
+
+
+
+
+ Mail Forwarder. Historical.
+
+
+
+
+
+
+ MG
+
+
+
+
+ Mail Group. Historical.
+
+
+
+
+
+
+ MINFO
+
+
+
+
+ Mail Information.
+
+
+
+
+
+
+ MR
+
+
+
+
+ Mail Rename. Historical.
+
+
+
@@ -13348,6 +13588,32 @@ view external {
+
+
+
+ NID
+
+
+
+
+ Holds values for Node Identifiers in
+ Identifier-Locator Network Protocol. Described
+ in RFC 6742.
+
+
+
+
+
+
+ NIMLOC
+
+
+
+
+ Nimrod Locator.
+
+
+
@@ -13361,6 +13627,18 @@ view external {
+
+
+
+ NSAP-PTR
+
+
+
+
+ Historical.
+
+
+
@@ -13425,6 +13703,18 @@ view external {
+
+
+
+ NULL
+
+
+
+
+ This is an opaque container.
+
+
+
@@ -13444,6 +13734,18 @@ view external {
+
+
+
+ OPENPGPKEY
+
+
+
+
+ Used to hold an OPENPGPKEY.
+
+
+
@@ -13578,6 +13880,19 @@ view external {
+
+
+
+ TLSA
+
+
+
+
+ Transport Layer Security Certificate Association.
+ Described in RFC 6698.
+
+
+
@@ -13590,6 +13905,54 @@ view external {
+
+
+
+ UID
+
+
+
+
+ Reserved.
+
+
+
+
+
+
+ UINFO
+
+
+
+
+ Reserved.
+
+
+
+
+
+
+ UNSPEC
+
+
+
+
+ Reserved. Historical.
+
+
+
+
+
+
+ URI
+
+
+
+
+ Holds a URI. Described in RFC 7553.
+
+
+
diff --git a/doc/misc/rfc-compliance b/doc/misc/rfc-compliance
index 4c87c66242..0f77218e9c 100644
--- a/doc/misc/rfc-compliance
+++ b/doc/misc/rfc-compliance
@@ -29,20 +29,79 @@ or Best Current Practice (BCP) documents.
RFC2181
RFC2230
RFC2308
- RFC2535 [3] [4]
RFC2536
- RFC2537
- RFC2538
RFC2539
- RFC2671
- RFC2672
- RFC2673
RFC2782
RFC2915
RFC2930
RFC2931 [5]
RFC3007
+ RFC3110
+ RFC3123
+ RFC3225
+ RFC3226
+ RFC3363 [6]
+ RFC3490 [7]
+ RFC3491 (Obsoleted by 5890, 5891) [7]
+ RFC3493
+ RFC3496
+ RFC3597
+ RFC3645
+ RFC4025
+ RFC4034
+ RFC4035
+ RFC4074
+ RFC4255
+ RFC4294 - Section 5.1 [8]
+ RFC4343
+ RFC4398
+ RFC4408
+ RFC4431
+ RFC4470 [9]
+ RFC4509
+ RFC4635
+ RFC4701
+ RFC4892
+ RFC4955 [10]
+ RFC5001
+ RFC5011
+ RFC5155
+ RFC5205
+ RFC5452 [11]
+ RFC5702
+ RFC5933 [12]
+ RFC5936
+ RFC5952
+ RFC5966
+ RFC6052
+ RFC6147 [13]
+ RFC6303
+ RFC6605 [14]
+ RFC6672
+ RFC6698
+ RFC6742
+ RFC6840 [15]
+ RFC6844
+ RFC6891
+ RFC7043
+ RFC7314
+ RFC7314
+The following DNS related RFC have been obsoleted
+
+ RFC2535 (Obsoleted by 4034, 4035) [3] [4]
+ RFC2537 (Obsoleted by 3110)
+ RFC2538 (Obsoleted by 4398)
+ RFC2671 (Obsoleted by 6891)
+ RFC2672 (Obsoleted by 6672)
+ RFC2673 (Obsoleted by 6891)
+ RFC3008 (Obsoleted by 4034, 4035)
+ RFC3152 (Obsoleted by 3596)
+ RFC3445 (Obsoleted by 4034, 4035)
+ RFC3655 (Obsoleted by 4034, 4035)
+ RFC3658 (Obsoleted by 4034, 4035)
+ RFC3755 (Obsoleted by 4034, 4035)
+ RFC3757 (Obsoleted by 4034, 4035)
[1] Queries to zones that have failed to load return SERVFAIL rather
than a non-authoritative response. This is considered a feature.
diff --git a/doc/rfc/index b/doc/rfc/index
index eddffa39c7..20e7b72b45 100644
--- a/doc/rfc/index
+++ b/doc/rfc/index
@@ -158,6 +158,7 @@
6840: Clarifications and Implementation Notes for DNS Security (DNSSEC)
6844: DNS Certification Authority Authorization (CAA) Resource Record
6891: Extension Mechanisms for DNS (EDNS(0))
+7043: Resource Records for EUI-48 and EUI-64 Addresses in the DNS
7314: Extension Mechanisms for DNS (EDNS) EXPIRE Option
7534: AS112 Nameserver Operations
7535: AS112 Redirection Using DNAME
diff --git a/doc/rfc/rfc7043.txt b/doc/rfc/rfc7043.txt
new file mode 100644
index 0000000000..e6a666e443
--- /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)",
+ .
+
+ [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)",
+ November 2012,
+ .
+
+ [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,
+ .
+
+ [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]
+