<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc1034 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
  <!ENTITY rfc1035 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
  <!ENTITY rfc2119 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category="exp" ipr="trust200902"
  docName="draft-jabley-dnsext-eui48-eui64-rrtypes-00">

  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Resource Records for EUI-48, EUI-64">Resource Records
      for EUI-48 and EUI-64 Addresses in the DNS</title>

    <author initials='J.' surname="Abley" fullname='Joe Abley'>
      <organization>TekSavvy Solutions, Inc.</organization>
      <address>
        <postal>
          <street>470 Moore Street</street>
          <city>London</city>
          <region>ON</region>
          <code>N6C 2C2</code>
          <country>Canada</country>
        </postal>
        <phone>+1 519 670 9327</phone>
        <email>jabley@teksavvy.ca</email>
      </address>
    </author>

    <date day="18" month="March" year="2013"/>

    <abstract>
      <t>EUI-48 and EUI-64 are address formats specified by the IEEE
        for use in various layer-2 networks, e.g. ethernet.</t>

      <t>This document defines two new DNS resource record types,
        EUI48 and EUI64, for encoding ethernet addresses in the DNS.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Domain Name System (DNS) is described in <xref
        target="RFC1034"/> and <xref target="RFC1035"/>. This
        base specification defines many Resource Record Types
        (RRTypes), and subsequent specifications have defined
        others. Each defined RRType provides a means of encoding
        particular data in the DNS.</t>

      <t><xref target="EUI48">EUI-48</xref> and
        <xref target="EUI64">EUI-64</xref> are address formats
        specified by the IEEE for use in various layer-2 networks,
        e.g. ethernet.</t>

      <t>This document defines two new Resource Record Types
        (RRTypes), EUI48 and EUI64 for encoding EUI-48 and
        EUI-64 addresses in the DNS.</t>
    </section>

    <section title="Terminology">
      <t>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 <xref target="RFC2119"/>.</t>
    </section>

    <section title="Presentation Format Considerations">
      <t>Various representations of EUI-48 and EUI-64 addresses
	are used in common implementations, depending on application
	and vendor preference. For example, the EUI-48 address
	7cd1c3e8102f might reasonably be represented as any of the
	following:

        <list style="symbols">
          <t>7cd1c3e8102f</t>
          <t>7c:d1:c3:e8:10:2f</t>
          <t>7c-d1-c3-e8-10-2f</t>
          <t>7cd1.c3e8.102f</t>
        </list>

        There is no canonical representation defined by the IEEE.</t>

      <t>The use of a single representation for use in the DNS
	promotes ease of implementation and information retrieval,
	and this document specifies (see <xref target="eui48pres"/>,
	<xref target="eui64pres"/>) that the second representation
	on this list be used, that of two-digit hexadecimal numbers
	separated by colons. The digits A through F may be represented
	in either upper or lower case.</t>
    </section>

    <section title="The EUI48 Resource Record">
      <t>The EUI48 RR is used to store EUI-48 addresses in the DNS.</t>

      <t>The Type value for the EUI48 RRType is XXTBA1.</t>

      <t>The EUI48 RR is class-independent.</t>

      <t>The EUI48 RR has no special TTL requirements.</t>

      <section title="EUI48 RDATA Wire Format">
        <t>The RDATA for an EUI48 RR consists of a single, 6-octet
          EUI48-Address field, encoded in network (big-endian) order.</t>

        <figure>
          <artwork>
                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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                                                 |
   |                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          </artwork>
        </figure>
      </section>

      <section title="EUI48 RR Presentation Format" anchor="eui48pres">
        <t>The Address field MUST be represented as six two-digit
          hexadecimal numbers separated by colons. The hexadecimal
          digits "A" through "F" MAY be represented in either upper
          or lower case.</t>
      </section>
    </section>

    <section title="The EUI64 Resource Record" anchor="eui64rr">
      <t>The EUI64 RR is used to store EUI-64 addresses in the DNS.</t>

      <t>The Type value for the EUI64 RR is XXTBA2.</t>

      <t>The EUI64 RR is class-independent.</t>

      <t>The EUI64 RR has no special TTL requirements.</t>
      
      <section title="EUI64 RDATA Wire Format">
        <t>The RDATA for an EUI48 RR consists of a single, 8-octet
          Address field, encoded in network (big-endian) order.</t>

        <figure>
          <artwork>
                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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                                                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          </artwork>
        </figure>
      </section>

      <section title="EUI64 RR Presentation Format" anchor="eui64pres">
	<t>The Address field MUST be represented as eight two-digit
	  hexadecimal numbers separated by colons. The hexadecimal
	  digits "A" through "F" may be represented in either upper
	  or lower case.</t>
      </section>
    </section>

    <section title="Examples">
      <t>The following EUI48 RR stores the EUI-48 address
        7c:d1:c3:e8:10:2f.</t>

      <figure>
        <artwork>
  host.example. 86400 IN EUI48 7c:d1:c3:e8:10:2f
        </artwork>
      </figure>

     <t>The following EUI64 RR stores the EUI-64 address
        7c:d1:c3:ff:fe:e8:10:2f.</t>

      <figure>
        <artwork>
  host.example. 86400 IN EUI64 7c:d1:c3:ff:fe:e8:10:2f
        </artwork>
      </figure>
    </section>

    <section title="IANA Considerations">
      <t>This document directs the IANA to assign two entries in the
        "Resource Record (RR) TYPEs" subregistry as follows:</t>

      <texttable>
        <ttcol>Type</ttcol>
        <ttcol>Value</ttcol>
        <ttcol>Meaning</ttcol>
        <ttcol>Reference</ttcol>

        <c>EUI48</c>
        <c>XXTBA1</c>
        <c>an EUI-48 address</c>
        <c>this document</c>

        <c>EUI64</c>
        <c>XXTBA2</c>
        <c>an EUI-64 address</c>
        <c>this document</c>
      </texttable>
    </section>

    <section title="Security Considerations">
      <t>The specification presented in this document presents no
        additional threat to the Internet.</t>
    </section>

    <section title="Acknowledgements">
      <t>Your name here, etc.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc1034;
      &rfc1035;
      &rfc2119;

      <reference anchor="EUI48">
        <front>
          <title>Guidelines for use of a 48-bit Extended Unique
            Identifier (EUI-48)</title>
          <author>
            <organization>IEEE</organization>
            <address/>
          </author>
        </front>
        <format type="PDF" target="http://standards.ieee.org/develop/regauth/tut/eui48.pdf"/>
      </reference>

      <reference anchor="EUI64">
        <front>
          <title>Guidelines for use of a 64-bit Extended Unique
            Identifier (EUI-64)</title>
          <author>
            <organization>IEEE</organization>
            <address/>
          </author>
        </front>
        <format type="PDF" target="http://standards.ieee.org/develop/regauth/tut/eui64.pdf"/>
      </reference>
    </references>

    <section title="Editorial Notes">
      <t>This section (and sub-sections) to be removed prior to
        publication.</t>

      <section title="RRType Parameter Allocation Template">
        <figure>
          <artwork>
                 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: joe.abley@icann.org
         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.
          </artwork>
        </figure>
      </section>

      <section title="Change History">
        <t>
          <list style="hanging">
            <t hangText="00">Initial idea, circulated for the purposes of
              entertainment.</t>
          </list>
        </t>
      </section>
    </section>
  </back>
</rfc>

