On 4/14/13 9:40 AM, Michael StJohns wrote:
What exactly is the purpose for this document? Specifically, please
> describe the concept of operations for the use of this record.
The rational described on this list a month ago was as follows:
-------- Original Message --------
Subject: [dnsext] Fwd: New Version Notification for
draft-jabley-dnsext-eui48-eui64-rrtypes-00.txt
Date: Tue, 19 Mar 2013 10:33:04 -0400
From: Joe Abley <jab...@hopcount.ca>
To: dns...@ietf.org Group <dns...@ietf.org>
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
> Mapping a name directly to a MAC address seems somewhat problematic
> and perhaps even dangerous to consistency.
>
> I understand storing things in the DNS system is attractive, but
> adapting it to store L2 data may be going a bit too far past it's
> designed scope,
The scope in which such a mapping is useful is clearly fairly limited, I
imagine there are provisioning/subscriber managment systems that would
adopt such a representation, but I imagine the author has a more
specifc example.
I would object to the document absent a clear and convincing
> description of why it is needed and what applications will use it.
>
> Mike
>
> Sent from my iPad
>
> On Apr 14, 2013, at 11:55, joel jaeggli <joe...@bogus.com> wrote:
>
>> I've been asked to take this document on as AD sponsored individual
>> submission.
>>
>> http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02
>>
>>
>>
If there's anyone who has strenuous objections to that, please let me know.
>> joel _______________________________________________ dnsext mailing
>> list dns...@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
