Subject: [dnsext] Fwd: New Version Notification for draft-jabley-dnsext-eui48-eui64-rrtypes-00.txt

From: Joe Abley <[email-masked]>
Date: Tue, 19 Mar 2013 10:33:04 -0400

Hi all,

During a conversation about an attempt to stuff IP and subscriber MAC addresses into the DNS (something that is happening operationally in Canada, related to wholesale cable internet service) I noticed that there is currently no clean way to represent ethernet MAC addresses. People are either using TXT records, or encoding MAC addresses into PTR RDATA, and it's all a bit messy.

Assuming that this is not the last time that someone will find a reason to encode layer-2 addresses in the DNS, I thought it worthwhile to define a cleaner option.

The draft referenced below defines two new RRTypes, EUI48 (for EUI-48 addresses, which is what prompted this line of thinking) and EUI64 (for EUI-64 addresses, since it seems silly to accommodate one without the other).

The wire format is pretty trivial (network byte order, simple octet string), the RRTypes chosen are unremarkable (not sure what else you'd call an EUI-48 address RRType than EUI48) and the presentation format should be familiar. The examples given use the ethernet address of the wireless adapter on my laptop and its EUI-64 mapping, for lack of any documentation OUI that I could find. The IEEE references are consistent with the references for EUI-64 in IPv6, e.g. in RFC 4291. The expert review template for the RRType application is included as an appendix.

In the event that this proposal doesn't meet with projectile heartburn, I would hope that this could be adopted, discussed, refined and last-called before the demise of dnsext. Alternatively, assuming again that the expert review raises no concerns and code points are assigned, it could proceed as an individual-track submission.

Comments welcome.

Joe

Begin forwarded message:

> From: <[email-masked]>
> Subject: New Version Notification for draft-jabley-dnsext-eui48-eui64-rrtypes-00.txt
> Date: 18 March 2013 18:08:11 EDT
> To: <[email-masked]>
> 
> 
> A new version of I-D, draft-jabley-dnsext-eui48-eui64-rrtypes-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Filename:	 draft-jabley-dnsext-eui48-eui64-rrtypes
> Revision:	 00
> Title:		 Resource Records for EUI-48 and EUI-64 Addresses in the DNS
> Creation date:	 2013-03-18
> Group:		 Individual Submission
> Number of pages: 15
> URL:             http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtypes-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes
> Htmlized:        http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-00
> 
> 
> Abstract:
>   EUI-48 and 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.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Jim Reid <[email-masked]>
Date: Tue, 19 Mar 2013 14:42:51 +0000

> In the event that this proposal doesn't meet with projectile heartburn, I would hope that this could be adopted, discussed, refined and last-called before the demise of dnsext. Alternatively, assum…

IMO, just shove this through the RFC5395 process and we're done. Nothing for the WG to see here, move along... Documenting this with an Informational or Individual RFC is nice too.

---

From: [email-masked]
Date: Fri, 22 Mar 2013 16:00:55 +0000

so to be clear,

ITU.hopcount.ca   in EUI64 0x0eedc231997faace

is valid?

where does one anchor the reverse map?

/bill

On Tue, Mar 19, 2013 at 10:33:04AM -0400, Joe Abley wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Mar 2013 17:09:43 +0100

> where does one anchor the reverse map?

http://www.alvestrand.no/objectid/top.html

   Patrik

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Mar 2013 12:21:26 -0400

> ITU.hopcount.ca   in EUI64 0x0eedc231997faace

IEEE, if you're making a reference to the origins of EUI64, but no; the -00 specifies

ITU.hopcount.ca. IN EUI64 0e:ed:c2:31:99:7f:fa:ce

There's a -01 which contains some changes, following discussions with the IETF's IEEE liaisons (and still waiting on some feedback from the IEEE) which changes the representation to

ITU.hopcount.ca. IN EUI64 0e-ed-c2-31-99-7f-fa-ce

since it appears (but has not yet been confirmed) that hyphen-separated, two-digit hex octets is the prescribed, canonical presentation format for such addresses.

> where does one anchor the reverse map?

No reverse map is defined. Such work could easily be discussed separately, although I think it's likely to be complicated by the fact that OUIs are maintained by an organisation that is quite distant from IANA (the IEEE).

I heard a suggestion the other day that address assignments under the IANA OUI (00-00-5E, see RFC 5342) could be represented under OUI.ARPA. That at least avoids the administrative complexities of coordination between IANA and the IEEE, but it's not obvious that there's an immediate use-case. Perhaps you have one in mind?

This work was inspired by what is essentially a loosely-dynamic documentation exercise, part of which encodes ethernet addresses in DNS zones. Lacking a resource record which would allow a clean, source-validated encoding of EUI-48 addresses, the result was a mismash of TXT records and contrived labels. This draft is motivated by a desire to make it easier for people to make better decisions in similar projects in the future.

(I've had some other feedback off-list that suggests EUI48/EUI64-like RRs would be useful for others, which is comforting. I don't always treasure the knowledge that I'm the only insane person on the block.)

Joe

---

From: [email-masked]
Date: Fri, 22 Mar 2013 16:22:40 +0000

> http://www.alvestrand.no/objectid/top.html

	yes yes...  

e.c.a.a.f.7.9.9.1.3.2.c.d.e.e.0.oid.int.  in [XXXX]  ITU.hopcound.ca.

seems to be missing the reverse semantics.  

/bill

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Mar 2013 12:23:54 -0400

> http://www.alvestrand.no/objectid/top.html

Unless I'm reading it wrong, that's a collection of object identifiers, variously maintained by IANA, ANSI and BSI (for various parts of the tree).

It's not obvious to me how that relates to IEEE OUIs or address assignments within individual OUIs. What did I miss?

Joe