I have reviewed this document as part of the security
directorate's ongoing effort to review all IETF documents
being processed by the IESG. These comments were written
primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments
just like any other last call comments.

This draft suggests two new DNS RRtypes that could encode IEEE
EUI-48 and EUI-64 layer-2 addresses.  There is at least one
known use case of a Canadian required reverse DNS mapping of
IP addresses to MAC addresses.

The draft is simple and straight forward and follows the usual
procedure for requesting a new RRtype.

Security concern.

You might want to mention that publication of the EUI's could
facilitate MAC cloning.

This isn't original to me.  I followed the reference to the Canadian
CRTC decision NTRE038D and looked at the various
company "contributions" that led to that decision.  One
contribution from Clearcable (NTCO0362, see


http://www.crtc.gc.ca/public/cisc/nt/NTCO0362.pdf

) speaks of the
risk that publication of EUI addresses in the global reverse DNS
would facilitate the theft of service that arises from cloning
the MAC address of a valid subscriber.  DOCSIS modem MAC cloning
does seem to be a known problem and concern, so perhaps this
should be mentioned.

The draft recommends restricting access to zones containing EUI64
addresses to limit the privacy exposure.  This is similar to the
recommendation in the NTRE038D to use a split-view reverse DNS
service.  The draft's recommendation would also limit the
exposure of valid EUI-64 addresses to MAC cloners, so I don't
think you need to describe additional countermeasures.

Nits and even more anal comments:

Section 9 says "with the Global bit zero".  I presume you mean
the next-to-least-significant-bit in the first octet.

RFC 5342 calls this bit the "Local bit" and the "Local/Global
bit".  RFC4291 calls this the "universal/local" bit.  The IEEE
802 standard talks about "universal" and "local" without actually
naming the bit, but lots of online documentation
says "universal/local" and "U/L".  So you and the RFC Editor can
decide what term to use.

IMHO: Continuing to call it the "Global bit" is my least favorite
choice.  Consistency with RFC5342 or RFC4291 would be preferable.

Section 9 says:
   Publication of EUI-48 or EUI-64 addresses in the global DNS may
   result in privacy issues in the form of unique trackable identities.

The privacy concern arises not just from the uniqueness of the
EUI but from the fact that it is a more permanent identifier than
the IP address associated with the subscriber (as the next
paragraph notes).  So "in the form of unique, permanent trackable
identities" is probably more accurate.  Similarly in the next
paragraph "EUI-64 addresses normally provide a unique identifier"
- the point is that the IP address "typically change over time"
so "provide a unique permanent identifier" is what you mean.  I
think.

The details of the IEEE references are incomplete.  I might have
recommended copying the references in RFC5342 but those
references look to be out of date.  I did find "Guidelines for
64-bit Global Identifier (EUI-64)"


http://standards.ieee.org/develop/regauth/tut/eui64.pdf

.  The URL
shown in RFC5342 for [EUI-64] redirects to that URL.

--Sandy