The (deprecated) MAC-48 is a concatenation of a 24-bit OUI assigned by the IEEE
Registration Authority and a 24-bit extension identifier assigned by the
organization with that OUI assignment.
The EUI-48™ is a concatenation of a 24-bit OUI value assigned by the IEEE
Registration Authority and a 24-bit extension identifier assigned by the
organization with that OUI assignment.
The (deprecated) EUI-60 is a concatenation of a 24-bit OUI assigned by the IEEE
Registration Authority and a 36-bit extension identifier assigned by the
organization with that OUI assignment.
The EUI-64™ is a concatenation of the 24-bit OUI value assigned by the IEEE
Registration Authority and a 40-bit extension identifier assigned by the
organization with that OUI assignment.
The EUI-48 and EUI-64 values are intended to be used within applications that
require fixed size universal identifiers. Other applications may elect to use
variable length identifiers (such as those defined in ASN.1, which support a
more flexible and extensible hierarchy of organizational identifiers).
The IEEE administers the assignment of 24-bit OUI values. The
assignments of these values are public, so that a user of a MAC-48, EUI-48, or
EUI-64 value can identify the manufacturer that provided any value[1]. The
IEEE/RAC has no control over the assignments of the extension identifiers and
assumes no liability for assignments of duplicate CDI-32, MAC-48, EUI-48, EUI-60,
or EUI-64
identifiers assigned by manufacturers.
The 24-bit OUI value is intended to identify the organization that
administers the remaining bits in EUI-48 and EUI-64 values. The OUI value
should not be used (in isolation) to identify a vendor or the format of
vendor-dependent information. When necessary to identify the vendor of a
hardware device, an EUI-48 (or EUI-64) identifier should be used. This allows
large organizations to assign distinct EUI-48 identifiers, so that each division
can be identified as a distinct "vendor". Alternatively, groups within an SDO
(standards development organization) can be identified by distinct EUI-48 (or
EUI-64) identifiers administered by their sponsoring body.
Identifier applications
In new applications, the OUI values are expected to generate extended
unique identifiers of the following forms used to generate extended unique
identifiers of the following forms:
- CDI-32.
A 32-bit identifier used to identify a small number
of design instances.
- EUI-48.
Limited uses include the following:
- A 48-bit identifier used to address hardware interfaces within existing 802
based networking applications
- A 48-bit identifier used to identify a design instance, as opposed to a
hardware instance. Examples include software interface standards (such as VGA), the model number for a product,
or the form/function of vendor-specific content.
- EUI-60.
(deprecated) A 60-bit identifier used to identify each hardware instance of a product, such
as a disk drive.
- EUI-64.
A 64-bit identifier used to identify each hardware instance of a product,
regardless of application, such as wireless devices and computerized toasters,
as well as EUI-48 identifier applications.
NOTE: When used to identify a hardware instance in new applications, the
IEEE/RAC intends to migrate from MAC-48
to EUI-64 identifiers. However, for backward compatibility, this
transition may be difficult for some 802-related applications. Therefore, policies
for allowing selective use of 48-bit identifiers within 802-related systems are
being developed (see the following subclause for further details).
The EUI-64 value was originally conceived as a mechanism to avoid excess
consumption of OUI values within high-volume non-networking applications.
Given the minimal probability of consuming all the EUI-64 identifiers, the
IEEE/RAC places minimal restrictions on their use within standards. Unless
mandated by backwards-compatibility constraints, the use of an EUI-64 is
preferred to the use of an EUI-48.
The terms EUI-48 and EUI-64 are trademarked by the IEEE. Companies are
allowed to use this term for commercial purposes, but only if their use of this
term has been reviewed by the IEEE/RAC and the proposed products using the
EUI-48 or EUI-64 conform to these restrictions.
CDI-32 identifier restrictions
In some applications, for example, in data communications
protocols that are sensitive to payload or throughput constraints, context-dependent
identifiers, based on the concatenation of a 24-bit OUI value with a 1-byte extension
identifier administered by the organization to which the OUI is assigned, have
been used. Such identifiers have typically been used in order to allow for vendor-defined
extensions to a base standard.
There are potential problems with the use of such identifiers
that make it preferable to use EUI-48 or EUI-64 wherever possible:
- If the context within which the assignment of
extension identifiers is required to be unique is not accurately defined,
then there is the danger of inadvertent re-use of an existing identifier
assignment for a different purpose, leading to ambiguity in the use of the
assigned values;
- If the chosen size of the extension identifier
is small relative to the actual number of identifier values that will need
to be assigned under a single OUI, then the result could be an unacceptable
rate of consumption of OUI values, and potential difficulty in the owner
of an OUI meeting the Registration Authority's requirement that 95% of the
block assignment represented by their existing OUI be consumed before making
use of a further assignment.
Consequently, the use of context-dependent identifiers
is acceptable, subject to the use meeting all of the following requirements:
- The context within which the context-dependent
identifier is used, and within which its identifier values are required
to be unique is clearly defined in the relevant standard.
- The size of the chosen extension identifier
is large enough to accommodate all conceivable requirements for the allocation
of distinct values under a single OUI within the defined context.
- The IEEE Registration Authority Committee (RAC)
has approved the identifier and the definition of the context within which
it will be used.
- Tutorial material that describes the context-dependent
identifier and its application, suitable for inclusion in this website,
is submitted to the IEEE Registration Authority Committee (RAC).
Further details are defined in Guidelines
for use of a 32-bit Context Dependent Identifier (CDE-32).
EUI-48 identifier restrictions
The 48-bit EUI-48 identifiers were originally created to serve as network or
media access control (MAC) addresses for local
area networks (LANs) by IEEE
Project 802. Within this environment,
EUI-48 identifiers are intended to identify items of real physical
equipment, parts of such equipment, or functions that apply to many instances of
physical equipment.
The use of 48-bit identifiers has been extended to serve as protocol
identifiers to identify protocol designs and design revisions of protocols
operating between instances of physical equipment, where
there are expected to be far fewer such
protocols identified than there are items of addressable physical equipment.
The total number of EUI-48 identifiers available, while large, is NOT
inexhaustible. The IEEE Registration Authority Committee (IEEE-RAC) has the duty
to promote the continued availability of the EUI-48 capability in conjunction
with IEEE standards and non-IEEE standards, for the benefit of the world-wide
community using those standards.
With the exception of such protocol identifiers, EUI-48 identifiers are
intended to identify items of real physical equipment or parts of such equipment
such as separable subsystems or individually addressable ports. The expected use
should not exceed one EUI-48 identifier per hardware subsystem or a most a very
low number of EUI-48 identifier per physical instances of such equipment (e.g.
groups of ports as in IEEE Std 802.3ad, for link aggregation). Allocation of a
single EUI-48 bit identifier to identify or permit addressing of a fixed and
permanent function associated with a real item of physical equipment occurs for
the lifetime of that equipment or an indefinite period of use.
In particular any application that called for subdivision of the available
number space, for block allocation to physical equipment without an identifiable
physical instance per EUI-48 identifier, or for encoding functional capabilities
within significant bits or bit patterns of the identifier, has the potential to
rapidly exhaust the address space. To reduce the prospect of exhaustion, new
applications and proposed extensions to current applications with significant
volume expectations are STRONGLY encouraged to make use of EUI-64, rather than
the EUI-48, to identify hardware instances.
New applications which
require address format matching to the existing base of EUI-48 equipment will be
reviewed by the IEEE-RAC and such exceptions will only be approved on a
case-by-case basis. Given the widespread use of hardware identifiers,
particularly within consumer based IP applications, the number of exceptions
(which use EUI-48 versus EUI-64 identifiers to identify hardware instances) is
expected to be small. Non-standard uses of EUI-48 are not supported.
The IEEE-RAC solicits any information that poses a threat to the viability of
the unique EUI-48/EUI-48/EUI-64 address space, whether an IEEE proposed standard
or another standard or specification. Further, in carrying out this duty to
preserve the longevity of these identifier capabilities, the RAC will act, via
liaison or direct coordination, to prevent potentially abusive uses for the
consumption of the OUI.
The IEEE-RAC regards the consistent enforcement of these restrictions as a
fundamental and realistic basis for ensuring longevity of the EUI-48 identifier
capability, with a target lifetime of 100 years for existing applications using
EUI-48 identifiers.
Further details are defined in Guidelines
for use of a 48-bit Extended Unique Identifier (EUI-48).
Nonoverlapping assignments
The organization that purchases an OUI is encouraged to assign only one
form of EUI-48 identifier, regardless of application. The
intent of this restriction is to reduce possible errors introduced by the
complexities of managing multiple context-dependent address spaces within
each organization.
Thus, the
EUI-48 values that specify I/O driver software interfaces, language codes, and
hardware model numbers never overlap. Similarly, the EUI-64 values that specify
I/O driver software interfaces, language codes, hardware model numbers, and
hardware instances never overlap. This no-overlap strategy is expected to reduce
unintentional duplication of EUI values, by elimination of subjective
application-class judgments, although a few more EUI values may be
consumed.
Null values
Many applications
have find it useful to define a distinct null identifier, most often
indicating the absence of a valid EUI-48 or EUI-64 value. The recommended
null values are FF-FF-FF-FF-FF-FF and FF-FF-FF-FF-FF-FF-FF-FF, for
EUI-48 and EUI-64 values respectively. Values based on a zero-valued OUI,
such as 00-00-00-00-00-00 and 00-00-00-00-00-00-00-00, must not be used,
since the OUI value of 00-00-00 has been assigned and could therefore
be used for other purposes.
Documentation of use
Given the possible confusions of bit ordering and byte
positioning, applications must clearly specify a mapping of the OUI value
(expressed as hexadecimal digits) to the applicable register or byte-string
sequence, in a unambiguous
manner. To ensure clarity, each mapping
should be self contained. If deemed necessary to cross-reference other documents
within a series, the specific document and page number shall be cross-referenced,
so that unfamiliar readers can easily find the source.
To avoid changes in existing standards, the working
group has the option of providing tutorials, to be posted on the IEEE/RAC web
site.
If a standard, or its cross-referenced portions of
other standards, does not conform with these documentation policies, the IEEE/RAC
can recommend the standard not be approved.
Identifier consumption
The manufacturer identifier assignment allows the assignee to generate
approximately 1 trillion (1012) unique EUI-64 values, by varying the
last 40 bits. Similarly, the assignee can generate approximately 69 billion
(109) unique EUI-60 values, by varying the last 36 bits. Alternatively, the assignee can generate approximately 16 million
(106) unique EUI-48 values, by varying the last 24 bits. The
IEEE intends not to assign another OUI value to a manufacturer until the
manufacturer has consumed, in product, the preponderance (more than 90%) of the
block of potential EUI-48, EUI-60, or EUI-64 words. It is incumbent upon the manufacturer
to ensure that large portions of the unique word block are not left unused in
manufacturing.
[1]Except for private OUI values, where the owner of the
OUI value is confidential. These remain private.
