Uniform Resource Names for Device IdentifiersEricssonJorvas02420Finlandjari.arkko@piuha.netCisco170 West Tasman DriveSan JoseCA95134USA+1 408 421-9990fluffy@cisco.com
Sensinode
Kidekuja 2Vuokatti88600FINLAND+358407796297zach@sensinode.comURNdevice identifierIMEI1-wireMAC addressEUI-48EUI-64This 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.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, as it fits in protocols mechanisms that are
designed to carry URNs , , . Finally, URNs
can also be easily carried and stored in formats such as XML or JSON . 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.This memo defines identity URN types for situations where no such
convenient type already exist. For instance, defines cryptographic identifiers,
defines International
Mobile station Equipment Identity (IMEI) identifiers for use with 3GPP
cellular systems, and
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.Universally Unique IDentifier (UUID) URNs
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.Future device identifier types can extend the device device URN
type defined here, or define their own URNs.The rest of this memo is organized as follows. defines the "DEV" URN type, and defines subtypes for IEEE MAC-48, EUI-48 and
EUI-64 addresses and 1-wire device identifiers.
gives examples. discusses the security
considerations of the new URN type. Finally,
specifies the IANA registration for the new URN type and sets
requirements for subtype allocations within this type.In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in .Namespace ID: "dev" requestedRegistration Information: This is the first registration of this namespace, 2011-08-27.Registration version number: 1Registration date: 2011-08-27Declared 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.Declaration of syntactic structure: The identifier is expressed in
ASCII (UTF-8) characters and has a hierarchical structure as
follows:The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA rules
defined in , which are not repeated here. The rule for unreserved is
defined in Section 2.3 of .The device identity namespace includes three subtypes, and more may be
defined in the future as specified in .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.Relevant ancillary documentation: See .Identifier uniqueness considerations: Device identifiers are
generally expected to be unique, barring the accidental issue of
multiple devices with the same identifiers.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.Process of identifier assignment: The process for identifier
assignment is dependent on the used subtype, and documented in the
specific subsection under .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.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.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.Validation Mechanism: Specific subtypes may be validated through
mechanisms discussed in .Scope: DEV URN is global in scope.DEV URNs of the "mac" subtype are based on the EUI-64 identifier
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.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.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.Identifier assignment for all of these identifiers rests within the
IEEE.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 .
*) 1-Wire is a registered trademark.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.Family code and identifier assignment for all 1-wire devices rests
with the manufacturers.The following three examples provide examples of MAC-based, 1-Wire, and Cryptographic
identifiers:
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.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.Additional subtypes for DEV URNs can be defined through IETF
Review or IESG Approval .Version -02 introduced several changes. The biggest change is that
with the NI URNs , 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 .The authors would like to thank Ari Keranen, Stephen Farrell,
Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, 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 or
.