One document matched: draft-arkko-core-dev-urn-02.xml
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902"
docName="draft-arkko-core-dev-urn-02"
category="info">
<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>
<front>
<title abbrev="DEV URN">Uniform Resource Names for Device Identifiers</title>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author initials="Z" surname="Shelby" fullname="Zach Shelby">
<organization>
Sensinode
</organization>
<address>
<postal>
<street>Kidekuja 2</street>
<city>Vuokatti</city>
<code>88600</code>
<country>FINLAND</country>
</postal>
<phone>+358407796297</phone>
<email>zach@sensinode.com</email>
</address>
</author>
<date month="July" year="2012" />
<keyword>URN</keyword>
<keyword>device identifier</keyword>
<keyword>IMEI</keyword>
<keyword>1-wire</keyword>
<keyword>MAC address</keyword>
<keyword>EUI-48</keyword>
<keyword>EUI-64</keyword>
<abstract>
<t>This memo describes a new Uniform Resource Name (URN) namespace for
hardware device identifiers. A general representation of device
identity can be useful in many applications, such as in sensor data
streams and storage, or equipment inventories. A URN-based
representation can be easily passed along in any application that
needs the information.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This memo describes a new Uniform Resource Name (URN)
<xref target="RFC2141"/> <xref target="RFC3406"/> namespace for
hardware device identifiers. A general representation of device
identity can be useful in many applications, such as in sensor data
streams and storage, or equipment inventories
<xref target="I-D.ietf-core-coap"/>,
<xref target="I-D.jennings-senml"/>,
<xref target="I-D.arkko-core-sleepy-sensors"/>
<xref target="I-D.arkko-core-security-arch"/>. A URN-based
representation can be easily passed along in any application that
needs the information, as it fits in protocols mechanisms that are
designed to carry URNs <xref target="RFC2616"/>, <xref
target="RFC3261"/>, <xref target="I-D.ietf-core-coap"/>. Finally, URNs
can also be easily carried and stored in formats such as XML <xref
target="W3C.REC-xml-19980210"/> or JSON <xref
target="I-D.jennings-senml"/> <xref target="RFC4627"/>. Using URNs in
these formats is often preferable as they are universally recognized,
self-describing, and therefore avoid the need for agreeing to
interpret an octet string as a specific form of a MAC address, for
instance.</t>
<t>This memo defines identity URN types for situations where no such
convenient type already exist. For instance, <xref
target="I-D.farrell-decade-ni"/> defines cryptographic identifiers,
<xref target="I-D.montemurro-gsma-imei-urn"/> defines International
Mobile station Equipment Identity (IMEI) identifiers for use with 3GPP
cellular systems, and <xref target="I-D.atarius-dispatch-meid-urn"/>
defines Mobile Equipment Identity (MEID) identifiers for use with
3GPP2 cellular systems. Those URN types should be employed when such
identities are transported; this memo does not redefine these
identifiers in any way.</t>
<t>Universally Unique IDentifier (UUID) URNs <xref target="RFC4122"/>
are another alternative way for representing device identifiers, and
already support MAC addresses as one of type of an
identifier. However, UUIDs can be inconvenient in environments where
it is important that the identifiers are as simple as possible and
where additional requirements on stable storage, real-time clocks, and
identifier length can be prohibitive. UUID-based identifiers are
recommended for all general purpose uses when MAC addresses are
available as identifiers. The device URN defined in this memo is
recommended for constrained environments.</t>
<t>Future device identifier types can extend the device device URN
type defined here, or define their own URNs.</t>
<t>The rest of this memo is organized as follows. <xref
target="devurn"/> defines the "DEV" URN type, and <xref
target="subtypes"/> defines subtypes for IEEE MAC-48, EUI-48 and
EUI-64 addresses and 1-wire device identifiers. <xref target="ex"/>
gives examples. <xref target="sec"/> discusses the security
considerations of the new URN type. Finally, <xref target="iana"/>
specifies the IANA registration for the new URN type and sets
requirements for subtype allocations within this type.</t>
</section>
<section anchor="kwd" title='Requirements language'>
<t>In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in <xref target='RFC2119' />.</t>
</section>
<section anchor="devurn" title="DEV URN Definition">
<t>Namespace ID: "dev" requested</t>
<t>Registration Information: This is the first registration of this namespace, 2011-08-27.</t>
<t>Registration version number: 1</t>
<t>Registration date: 2011-08-27</t>
<t>Declared registrant of the namespace: IETF and the CORE working
group. Should the working group cease to exist, discussion should be
directed to the general IETF discussion forums or the IESG.</t>
<t>Declaration of syntactic structure: The identifier is expressed in
ASCII (UTF-8) characters and has a hierarchical structure as
follows:</t>
<figure>
<artwork>
devurn = "urn:dev:" body componentpart
body = macbody / owbody / otherbody
macbody = "mac:" hexstring
owbody = "ow:" hexstring
otherbody = subtype ":" identifier
subtype = ALPHA *(DIGIT / ALPHA)
identifier = 1*unreserved
componentpart = [ ";" component [ componentpart ]]
component = *1(DIGIT / ALPHA)
hexstring = hexbyte /
hexbyte hexstring
hexbyte = hexdigit hexdigit
hexdigit = DIGIT / hexletter
hexletter = "a" / "b" / "c" / "d" / "e" / "f"
</artwork>
</figure>
<t>The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA rules
defined in <xref target="RFC5234"/>, which are not repeated here. The rule for unreserved is
defined in Section 2.3 of <xref target="RFC3986"/>.</t>
<t>The device identity namespace includes three subtypes, and more may be
defined in the future as specified in <xref target="iana"/>.</t>
<t>The optional components following the hexstring are strings depicting individual aspects of
a device. The specific strings and their semantics are up to the designers of the device, but
could be used to refer to specific interfaces or functions within the device.</t>
<t>Relevant ancillary documentation: See <xref
target="subtypes"/>.</t>
<t>Identifier uniqueness considerations: Device identifiers are
generally expected to be unique, barring the accidental issue of
multiple devices with the same identifiers.</t>
<t>Identifier persistence considerations: This URN type SHOULD only be
used for persistent identifiers, such as hardware-based identifiers or
cryptographic identifiers based on keys intended for long-term
usage.</t>
<t>Process of identifier assignment: The process for identifier
assignment is dependent on the used subtype, and documented in the
specific subsection under <xref target="subtypes"/>.</t>
<t>Process for identifier resolution: The device identities are not
expected to be globally resolvable. No identity resolution system is
expected. Systems may perform local matching of identities to previously
seen identities or configured information, however.</t>
<t>Rules for Lexical Equivalence: The lexical equivalence of the DEV
URN is defined as an exact and case sensitive string match. Note that
the two subtypes defined in this document use only lower case letters,
however. Future types might use identifiers that require other
encodings that require a more full-blown character set (such as
BASE64), however.</t>
<t>Conformance with URN Syntax: The string representation of the device
identity URN and of the MEID sub namespace is fully compatible with
the URN syntax.</t>
<t>Validation Mechanism: Specific subtypes may be validated through
mechanisms discussed in <xref target="subtypes"/>.</t>
<t>Scope: DEV URN is global in scope.</t>
</section>
<section anchor="subtypes" title="DEV URN Subtypes">
<section anchor="mac" title="MAC Addresses">
<t>DEV URNs of the "mac" subtype are based on the EUI-64 identifier
<xref target="IEEE.EUI64"/> derived from a device with a built-in
64-bit EUI-64. The EUI-64 is formed from 24 or 36 bits of organization
identifier followed by 40 or 28 bits of device-specific extension
identifier assigned by that organization.</t>
<t>In the DEV URN "mac" subtype the hexstring is simply the full
EUI-64 identifier represented as a hexadecimal string. It is always
exactly 16 characters long.</t>
<t>MAC-48 and EUI-48 identifiers are also supported by the same DEV
URN subtype. To convert a MAC-48 address to an EUI-64 identifier, The
OUI of the Ethernet address (the first three octets) becomes the
organization identifier of the EUI-64 (the first three octets). The
fourth and fifth octets of the EUI are set to the fixed value FFFF
hexadecimal. The last three octets of the Ethernet address become the
last three octets of the EUI-64. The same process is used to convert
an EUI-48 identifier, but the fixed value FFFE is used instead.</t>
<t>Identifier assignment for all of these identifiers rests within the
IEEE.</t>
</section>
<section anchor="1wire" title="1-Wire Device Identifiers">
<t>The 1-Wire* system is a device communications bus system designed
by Dallas Semiconductor Corporation. 1-Wire devices are identified by
a 64-bit identifier that consists of 8 byte family code, 48 bit
identifier unique within a family, and 8 bit CRC code <xref
target="OW"/>.
<list style="empty">
<t>*) 1-Wire is a registered trademark.</t>
</list>
</t>
<t>In DEV URNs with the "ow" subtype the hexstring is a representation
of the full 64 bit identifier as a hexadecimal string. It is always
exactly 16 characters long. Note that the last two characters
represent the 8-bit CRC code. Implementations MAY check the validity
of this code.</t>
<t>Family code and identifier assignment for all 1-wire devices rests
with the manufacturers.</t>
</section>
</section>
<section anchor="ex" title="Examples">
<t>The following three examples provide examples of MAC-based, 1-Wire, and Cryptographic
identifiers:
<figure>
<artwork>
urn:dev:mac:0024befffe804ff1 # The MAC address of
# Jari's laptop
urn:dev:ow:10e2073a01080063 # The 1-Wire temperature
# sensor in Jari's
# kitchen
urn:dev:ow:264437f5000000ed;humidity # The laundry sensor's
# humidity part
urn:dev:ow:264437f5000000ed;temperature # The laundry sensor's
# humidity part
</artwork>
</figure>
</t>
</section>
<section anchor="sec" title="Security Considerations">
<t>On most devices, the user can display device identifiers. Depending
on circumstances, device identifiers may or may not be modified or
tampered by the user. An implementation of the DEV URN MUST NOT change
these properties from what they were intended. In particular, a device
identifier that is intended to be immutable should not become mutable
as a part of implementing the DEV URN type. More generally, nothing in
this memo should be construed to override what the relevant device
specifications have already said about the identifiers.</t>
<t>Other devices in the same network may or may not be able to
identify the device. For instance, on Ethernet network, the MAC
address of a device is visible to all other devices.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>Additional subtypes for DEV URNs can be defined through IETF
Review or IESG Approval <xref target="RFC5226"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2141.xml"?>
<?rfc include="reference.RFC.3406.xml"?>
<?rfc include="reference.RFC.3986.xml"?>
<?rfc include="reference.RFC.5226.xml"?>
<?rfc include="reference.RFC.5234.xml"?>
<?rfc include="reference.IEEE.EUI64.xml"?>
<?rfc include="reference.OW.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2616.xml"?>
<?rfc include="reference.RFC.3261.xml"?>
<?rfc include="reference.RFC.3971.xml"?>
<?rfc include="reference.RFC.3972.xml"?>
<?rfc include="reference.RFC.4122.xml"?>
<?rfc include="reference.RFC.4627.xml"?>
<?rfc include="reference.W3C.REC-xml-19980210.xml"?>
<?rfc include="reference.I-D.draft-ietf-core-coap-06.xml"?>
<?rfc include="reference.I-D.jennings-senml.xml"?>
<?rfc include="reference.I-D.farrell-decade-ni.xml"?>
<?rfc include="reference.I-D.arkko-core-sleepy-sensors.xml"?>
<?rfc include="reference.I-D.arkko-core-security-arch.xml"?>
<?rfc include="reference.I-D.montemurro-gsma-imei-urn.xml"?>
<?rfc include="reference.I-D.atarius-dispatch-meid-urn.xml"?>
</references>
<section title="Changes from Previous Version">
<t>Version -02 introduced several changes. The biggest change is that
with the NI URNs <xref target="I-D.farrell-decade-ni"/>, it was no
longer necessary to define cryptographic identifiers in this
specification. Another change was that we incorporated a more generic
syntax for future extensions; non-hexstring identifiers can now also
be supported, if some future device identifiers for some reason would,
for instance, use BASE64. As a part of this change, we also changed
the component part separator character from '-' to ';' so that the
general format of the rest of the URN can employ the unreserved
characters <xref target="RFC3986"/>.</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Ari Keranen, Stephen Farrell,
Christer Holmberg, Peter Saint-Andre, and Ahmad Muhanna for
interesting discussions in this problem space. We would also like to
note prior documents that focused on specific device identifiers, such
as <xref target="I-D.montemurro-gsma-imei-urn"/> or <xref
target="I-D.atarius-dispatch-meid-urn"/>.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:21:25 |