Hubbry Logo
Organizationally unique identifierOrganizationally unique identifierMain
Open search
Organizationally unique identifier
Community hub
Organizationally unique identifier
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Organizationally unique identifier
Organizationally unique identifier
Organizationally unique identifier
View on Wikipedia
from Wikipedia

An organizationally unique identifier (OUI) is a 24-bit number that uniquely identifies a vendor, manufacturer, or other organization.

OUIs are purchased from the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority by the assignee (IEEE term for the vendor, manufacturer, or other organization). Only an assignment from the MA-L registry assigns a new OUI. They are used to uniquely identify individual pieces of equipment through derived identifiers such as MAC addresses,[1][2] Subnetwork Access Protocol protocol identifiers, World Wide Names for Fibre Channel devices or vendor blocks in EDID.[1]

In MAC addresses, the OUI is combined with a 24-bit number (assigned by the assignee of the OUI) to form the address. The first three octets of the address are the OUI.

Representation and formatting conventions

[edit]

The following terms are defined (either implicitly or explicitly) in IEEE Standard 802-2001 for use in referring to the various representations and formats of OUIs and the identifiers that may be created using them.[3]

Hexadecimal representation

[edit]

“The representation of a sequence of octet values in which the values of the individual octets are displayed in order from left to right, with each octet value represented as a two-digit hexadecimal numeral, and with the resulting pairs of hexadecimal digits separated by hyphens. The order of the hexadecimal digits in each pair, and the mapping between the hexadecimal digits and the bits of the octet value, are derived by interpreting the bits of the octet value as a binary numeral using the normal mathematical rules for digit significance.”[3] (See hexadecimal).

Canonical format

[edit]

"The format of a MAC data frame in which the octets of any MAC addresses conveyed in the MAC user data field have the same bit ordering as in the Hexadecimal Representation."[3] (See MAC data frame, MAC addresses)

Significance order

[edit]

This appears from the context of the IEEE Standard 802-2001 to be another term for the 'Hexadecimal Representation' – i.e., "by interpreting the bits of the octet value as a binary numeral using the normal mathematical rules for digit significance."[3]

Bit-reversed representation

[edit]

"The representation of a sequence of octet values in which the values of the individual octets are displayed in order from left to right, with each octet value represented as a two-digit hexadecimal numeral, and with the resulting pairs of hexadecimal digits separated by colons. The order of the hexadecimal digits in each pair, and the mapping between the hexadecimal digits and the bits of the octet value, are derived by reversing the order of the bits in the octet value and interpreting the resulting bit sequence as a binary numeral using the normal mathematical rules for digit significance."[3]

The bit-reversed representation corresponds to the convention of transmitting the least-significant-bit of each byte first in serial data communications.

Noncanonical representation

[edit]

"The format of a MAC data frame in which the octets of MAC addresses conveyed in the MAC user data field have the same bit ordering as in the Bit-reversed representation."[3]

Transmission order

[edit]

The order in which an octet or a sequence of octets is transmitted over the transmission medium – this order normally corresponds to the bit-reversed representation.

Example:

An OUI consisting of the hexadecimal digits ACDE4816 would be represented as follows:

The following figure shows the position of these bits in significance order: 

|            OUI                 |
| Octet 0  | Octet 1  | Octet 2  |
|  nibble  |  nibble  |  nibble  |
|  __||__  |  __||__  |  __||__  |
| |      | | |      | | |      | |
| 0  ||  1 | 2  ||  3 | 4  ||  5 |
|bits||bits|bits||bits|bits||bits|
|7654||3210|7654||3210|7654||3210|
|||||  |||||||||  |||||||||  |||||
|  A     C |  D     E |  4     8 |
|1010  1100|1101  1110|0100  1000|
 |    |  ||                 |   |
 |    |  ||                 |   least-significant-bit of OUI
 |    |  ||                 least-significant-byte of OUI
 |    |  |least-significant-bit of first octet of OUI = I/G or M bit
 |    |  next-to-least-significant-bit of first octet of OUI = U/L or X bit
 |    most-significant-byte of OUI
 most-significant-bit of OUI

Notes:

  1. The OUI of AC-DE-48 could be in use and is not a reserved value.
  2. 'F' and 'h' represent any hexadecimal number.
  3. 'c' represents the digits of the OUI, and 'e' represents the digits of the extension identifier supplied by the organization to whom the OUI is registered.

Potential for confusion in token ring

[edit]

Ethernet users are used to seeing canonical form, such as in the output of the ifconfig command. Canonical form is the intended standard.

However, since IEEE 802.3 (Ethernet) and IEEE 802.4 (Token Bus) send the bytes (octets) over the wire, left-to-right, with least significant bit in each byte first, while IEEE 802.5 (Token Ring) and IEEE 802.6 (FDDI) send the bytes over the wire with the most significant bit first, confusion may arise when an OUI in the latter scenario is represented with bits reversed from the canonical representation. So for instance, an OUI whose canonical form is ACDE48 could be seen written as 357B12 if translation is done improperly or inconsistently. The latter form (bit-reversed or noncanonical representation), may also be referred to in the literature as "MSB format", "IBM format", or "Token Ring format" for this reason. RFC2469 explains the problem in more detail.

Format

[edit]

The OUI is normally discussed and represented as a set of octets in hexadecimal notation separated by dashes (i.e., FF-FF-FF) or as a set of octets separated by colons in bit-reversed notation (i.e., FF:FF:FF).[4]

The two least-significant-bits of the second nibble of the first octet of the hexadecimal representation (i.e., the two least significant bits of the first octet) of the OUI are reserved as flag bits for some protocols (e.g., 'M' bit and 'X' bit), flags to indicate whether the address is part of an individual (unicast) or group (multicast) address block (e.g., Individual/Group [I/G] bit or Unicast/Multicast [U/M] bit), flags to indicate whether an address is universally or locally administered (e.g., Universal/Local [U/L] bit), etc., and should not contain the values 1, 2, 3, 5, 6, 7, 9, a, b, d, e, or f, unless these values reflect the true meaning of these flag bits – if the organization that owns the OUI does set one of these bits when creating an identifier, then the value of the second nibble of the first octet changes accordingly in representations of the OUI (e.g., if the hexadecimal value of the second nibble of the first octet is 'C' and the least-significant-bit is set, then the value becomes 'D').

Notes:

  1. "Three-octet values occupying the same fields as OUIs can occupy, but with the next-to-LSB of the first octet set to 1, are locally assigned and have no relationship to the IEEE-assigned values..."[4]
  2. The IEEE also has Company ID (CID) where the four least significant bits of Octet 0 are designated the M bit, X bit, Y bit, and Z bit, respectively, beginning with the least significant bit. In the CID, the M, X, Y, and Z bits have the values 0, 1, 0, and 1, respectively.[5]

Types of identifiers

[edit]

32-bit context-dependent identifier (CDI-32)

[edit]

The CDI-32 was historically recommended as a context-dependent identifier that was formed by concatenating the 24-bit OUI with an 8-bit extension identifier that is assigned by the organization that purchased the OUI – the resulting identifier was generally represented as a set of octets separated by dashes (hexadecimal notation) or colons (bit-reversed notation) as in FF-FF-FF-FF or FF:FF:FF:FF, as a string of 4 bytes as in {FF,FF,FF,FF}, or as a base 16 number as in FFFFFFFF16.[5]

40-bit context-dependent identifier (CDI-40)

[edit]

The CDI-40 was historically recommended as context-dependent identifier that was formed by concatenating the 24-bit OUI with a 16-bit extension or by concatenating a 36-bit OUI-36 with a 4-bit extension.[5] In either case, the extension was assigned by the organization that purchased the OUI. The resulting identifier was generally represented as a set of octets separated by dashes (hexadecimal notation) or colons (bit-reversed notation) as in FF-FF-FF-FF-FF or FF:FF:FF:FF:FF, as a string of 5 bytes as in {FF,FF,FF,FF,FF}, or as a base 16 number as in FFFFFFFFFF16.

Note: There were also IAB based CDI-40 sequences that were formed by combining the 36-bit IEEE assigned IAB base value with the 4-bit extension identifier assigned by the organization – e.g., if the IEEE assigned IAB base value is 0x0050C257A and the 4-bit extension identifier is 0xF, then the CDI-40 values generated by combining these two numbers are from 0x0050C257AF00 to 0x0050C257AFFF

48-bit media access control identifier (MAC-48)

[edit]

The IEEE now considers the label MAC-48 to be an obsolete term which was previously used to refer to a specific type of EUI-48 identifier used to address hardware interfaces (e.g., Network Interface Controllers and other network hardware) within existing IEEE 802 based networking applications and should not be used in the future.[5] Instead, the term EUI-48 should be used by manufacturers and others in the field for this purpose – i.e., MAC-48 identifier is identical to the EUI-48 identifier and is an obsolete label for it, although some distinction is still made when encapsulating MAC-48 and EUI-48 identifiers within EUI-64 identifiers (but now, the encapsulating mechanism is also deprecated).[5]

48-bit extended unique identifier (EUI-48)

[edit]

The EUI-48 is an identifier that is formed by concatenating the 24-bit OUI with a 24-bit extension identifier that is assigned by the organization that purchased the OUI – the resulting identifier is generally represented as a set of octets separated by dashes (hexadecimal notation) or colons (bit-reversed notation) as in FF-FF-FF-FF-FF-FF or FF:FF:FF:FF:FF:FF, as a string of 6 bytes as in {FF,FF,FF,FF,FF,FF}, or as a base 16 number as in FFFFFFFFFFFF16.[5]

60-bit extended unique identifier (EUI-60)

[edit]

The EUI-60 is an identifier that is formed by concatenating the 24-bit OUI with a 36-bit extension identifier that is assigned by the organization that purchased the OUI – the resulting identifier is generally represented by a string of 15 nibbles, as a base 16 number as in FFFFFFFFFFFFFFF16, or as FF-FF-FF:F.F.F.F.F.F.F.F.F as an EUI-64 value.[5]

Note: This identifier was previously used as the worldwide name (WWN) identifier within some storage systems. Its use is now considered deprecated by the IEEE and the EUI-64 identifier should be used in the future for this and all other purposes for which the EUI-60 was previously used. Some of the storage systems in which an OUI based variant was used are Fibre Channel, and Serial Attached SCSI (SAS).[5]

64-bit extended unique identifier (EUI-64)

[edit]

The EUI-64 is an identifier that is formed by concatenating the 24-bit OUI with a 40-bit extension identifier that is assigned by the organization that purchased the OUI – the resulting identifier is generally represented as a set of octets separated by dashes (hexadecimal notation) or colons (bit-reversed notation) as in FF-FF-FF-FF-FF-FF-FF-FF or FF:FF:FF:FF:FF:FF:FF:FF, as a string of 8 bytes as in {FF,FF,FF,FF,FF,FF,FF,FF}, or as a base 16 number as in FFFFFFFFFFFFFFFF16.[5]

Note: According to the IEEE guidelines, the first four digits of the organizationally assigned identifier (i.e., the first four digits of the extension identifier) portion of an EUI-64 “shall not be FFFE16 or FFFF16” (i.e., EUI-64 identifiers of the form ccccccFFFEeeeeee and ccccccFFFFeeeeee are not allowed) – this is to support the encapsulation of EUI-48 (FFFE16) and MAC-48 (FFFF16) values into EUI-64 values (though now the encapsulation is deprecated).

Other identifiers

[edit]

IPv6 uses a 64-bit Modified Extended Unique Identifier (Modified EUI-64) in the lower half of some IPv6 addresses. A Modified EUI-64 is an EUI-64 with the U/L bit inverted.[6]

There are other identifiers that may be formed using the OUI but those listed above are the most commonly used.

Encapsulating

[edit]

Mapping an EUI-48 to an EUI-64 is deprecated. The mapping is described here for historical reasons.

Other identifiers, such as MAC-48 and EUI-48 values, can be contained within a larger identifier or 'container', such as EUI-64, by creating the larger identifier through a process of combining the smaller identifier with specified values placed in specified bit-positions within the larger identifier – this process is known as 'encapsulation' and is provided for the purpose of easing the transition from MAC-48 and EUI-48 to EUI-64 and to provide a mechanism for the conversion of MAC-48 and EUI-48 identifiers to EUI-64 in such a way that duplicate or conflicting values are avoided.[5]

Encapsulation examples

[edit]

Encapsulation of MAC-48 within EUI-64 Example:

Assuming that an organization has registered the OUI of AC-DE-48 and that the organization has created the MAC-48 value of AC-DE-48-23-45-67 by concatenating the extension identifier 23-45-67, this MAC-48 identifier has the following binary transmission order: 

 |            OUI             |     extension identifier   | field
 |  1st   |   2nd   |  3rd    |   4th   |   5th   |   6th  | octet
 | C   A  |  E   D  |  8   4  |  3   2  |  5   4  |  7   6 | hex
 0011 0101 0111 1011 0001 0010 1100 0100 1010 0010 1110 0110 bits
 |       | |       | |       | |       | |       | |       |
 lsb   msb lsb   msb lsb   msb lsb   msb lsb   msb lsb   msb

The same MAC-48 identifier after encapsulation within an EUI-64 has the following transmission order: 

 |           OUI           |    MAC label    |   extension identifier  | field
 |  1st  |  2nd   |  3rd   |  4th   |  5th   |  6th   |  7th   |  8th  | order
 | C  A  |  E  D  |  8  4  |  F  F  |  F  F  |  3  2  |  5  4  |  7  6 | hex
 00110101 01111011 00010010 11111111 11111111 11000100 10100100 11100110 bits
 |      | |      | |      | |      | |      | |      | |      | |      |
 lsb  msb lsb  msb lsb  msb lsb  msb lsb  msb lsb  msb lsb  msb lsb  msb

The same MAC-48 identifier after encapsulation within an EUI-64 has the following significance order: 

 |           OUI           |    MAC label    |   extension identifier  | field
 |  AC   |   DE   |   48   |   FF   |   FF   |   23   |   45   |   67  | hex
 10101100 11011110 01001000 11111111 11111111 00100011 01000101 01100111 bits
 |  |                                                               |  |
 |  most-significant-byte                      least-significant-byte  |
 most-significant-bit                              least-significant-bit

Encapsulation of EUI-48 within EUI-64 example:

Assuming that an organization has registered the OUI of AC-DE-48 and that the organization has created the EUI-48 value of AC-DE-48-23-45-67 by concatenating the extension identifier 23-45-67, this EUI-48 identifier has the following format in significance order: 

 |        company_id       |   extension identifier  | field
 |  AC   |   DE   |   48   |   23   |   45   |   67  | hex
 10101100 11011110 01001000 00100011 01000101 01100111 bits
 |  |                                             |  |
 |  most-significant-byte    least-significant-byte  |
 most-significant-bit            least-significant-bit

The same EUI-48 identifier after encapsulation within an EUI-64 has the following format in significance order: 

 |        company_id       |    EUI label    |   extension identifier  | field
 |  AC   |   DE   |   48   |   FF   |   FE   |   23   |   45   |   67  | hex
 10101100 11011110 01001000 11111111 11111110 00100011 01000101 01100111 bits
 |  |                                                               |  |
 |  most-significant-byte                      least-significant-byte  |
 most-significant-bit                              least-significant-bit

Encapsulation of MAC-48 or EUI-48 within modified EUI-64 example:

In the encapsulation within a Modified EUI-64 a MAC-48 is treated as an EUI-48 and the U/L bit is inverted.[6] Assuming that an organization has registered the OUI of AC-DE-48 and that the organization has created the MAC-48 or EUI-48 value of AC-DE-48-23-45-67 by concatenating the extension identifier 23-45-67, this MAC-48 or EUI-48 identifier has the following format in significance order: 

 |        company_id       |   extension identifier  | field
 |  AC   |   DE   |   48   |   23   |   45   |   67  | hex
 10101100 11011110 01001000 00100011 01000101 01100111 bits
 |  |                                             |  |
 |  most-significant-byte    least-significant-byte  |
 most-significant-bit            least-significant-bit

The same MAC-48 or EUI-48 identifier after encapsulation within a Modified EUI-64 has the following format in significance order: 

 |        company_id       |    EUI label    |   extension identifier  | field
 |  AE   |   DE   |   48   |   FF   |   FE   |   23   |   45   |   67  | hex
 10101110 11011110 01001000 11111111 11111110 00100011 01000101 01100111 bits
 |  |                                                               |  |
 |  most-significant-byte                      least-significant-byte  |
 most-significant-bit                              least-significant-bit

NAA Name_Identifier

[edit]

Network Address Authority (NAA) Name_Identifier formats define the first nibble (4 bits) to define the format of the identifier:

Value NAA type Length
1h NAA IEEE 48-bit 8 bytes
2h NAA IEEE Extended 8 bytes
5h NAA IEEE Registered 8 bytes
6h NAA IEEE Registered Extended 16 bytes
Ch, Dh, Eh, Fh NAA EUI-64 Mapped 8 bytes

This encapsulation is used in Fibre Channel[7] and SAS, and is also supported in iSCSI in RFC 3980. This addition requires either a shortened vendor-specific identifier field, or some OUI bits are assumed to be 0, such as when using EUI-64 Mapped format.

Individual Address Block

[edit]

An Individual Address Block (IAB) is an inactive registry activity which has been replaced by the MA-S registry product as of 1 January 2014. The IAB uses a MA-L (and OUI) belonging to the IEEE Registration Authority, concatenated with 12 additional IEEE-provided bits (for a total of 36 bits), leaving only 12 bits for the IAB owner to assign to their (up to 4096) individual devices. An IAB is ideal for organizations requiring not more than 4096 unique 48-bit numbers (EUI-48). Unlike an OUI, which allows the assignee to assign values in various different number spaces (for example, EUI-48, EUI-64, and the various context-dependent identifier number spaces), the Individual Address Block could only be used to assign EUI-48 identifiers. All other potential uses based on the OUI from which the IABs are allocated are reserved and remain the property of the IEEE Registration Authority. It should also be noted that, between 2007 and September 2012, the OUI value 00:50:C2 was used for IAB assignments. After September 2012, the value 40:D8:55 was used. The owners of an already assigned IAB may continue to use the assignment.[8][5]

The OUI-36 is a deprecated registry activity name, which has been replaced by the MA-S registry product name as of 1 January 2014. This registry activity includes both a 36-bit unique number used in some standards and the assignment of a block of EUI-48 and EUI-64 identifiers (while owner of IAB cannot assign EUI-64) by the IEEE Registration Authority. The owner of an already assigned OUI-36 registry product may continue to use the assignment.

Example of EUI-48 created within an IAB: An EUI-48 identifier is formed by combining the 36-bit IEEE-assigned IAB base value with a 12-bit extension identifier assigned by the organization – e.g., if the IEEE-assigned IAB base-16 value is 0x0050C257A and the 12-bit extension identifier is 0xFFF, then the EUI-48 value generated by combining these two numbers is 0x0050C257AFFF.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Organizationally unique identifier

View on Grokipedia
from Grokipedia
An Organizationally Unique Identifier (OUI) is a 24-bit globally assigned by the IEEE to organizations, vendors, or manufacturers for use in creating unique identifiers within various technical standards, particularly in networking protocols. OUIs form the initial 24 bits of extended unique identifiers (EUIs), such as EUI-48 and EUI-64, which are concatenated with organization-supplied bits to generate full addresses like MAC addresses in standards for Ethernet, , and devices. This structure ensures that devices from different manufacturers can operate without address conflicts across global networks. Organizations obtain an OUI through an application process with the IEEE , which reviews and assigns the identifier after payment of a one-time fee, typically processed within seven business days. The IEEE maintains a public registry of assigned OUIs, enabling tools and systems to map the first three bytes of a to the corresponding vendor or organization. Beyond MAC addressing, OUIs are referenced in standards like the Subnetwork Access Protocol (SNAP) for protocol identification and in other contexts requiring organizational uniqueness, such as addresses or vendor-specific extensions in IEEE protocols. This system, managed by the IEEE since the early development of local area networking standards, supports and traceability in modern connected technologies.

Definition and Purpose

Core Concept and Role in Networking

An Organizationally Unique Identifier (OUI) is a 24-bit value, comprising the first three octets, that is uniquely assigned by the IEEE to manufacturers, vendors, or other organizations to guarantee global uniqueness for hardware and network identifiers. This identifier serves as the foundational prefix in various extended formats, ensuring that devices can be distinctly recognized across diverse networking environments without address conflicts. The primary role of an OUI in networking lies in its use to construct globally unique addresses, such as Extended Unique Identifiers (EUI-48 and EUI-64), which form the basis for in standards. By prefixing these addresses, OUIs prevent collisions in protocols supporting Ethernet, (), Bluetooth, and neighbor discovery, while also facilitating vendor identification through analysis of network traffic—such as in security monitoring or device profiling. For instance, the OUI portion of a allows network administrators to trace the manufacturer of a connected device. OUIs originated in the alongside the development of standards for local and metropolitan area networks, building on early Ethernet addressing schemes to standardize unique identification. With the 24-bit space offering over 16 million possible values, widespread adoption has prompted exhaustion concerns, particularly for EUI-48 usage, leading the IEEE to promote EUI-64 and introduce smaller allocation options like Block Small (MA-S) to extend the address space's longevity beyond the targeted 100-year horizon from 1980.

Assignment Process and IEEE Administration

The IEEE Registration Authority (RA), operating under the and accessible via standards.ieee.org/products-programs/regauth/, functions as the centralized body responsible for administering and assigning Organizationally Unique Identifiers (OUIs) to organizations worldwide, a role it has fulfilled since 1986 to ensure unique identification in networking standards. The assignment process requires organizations to submit an online application through the RA portal at regauth.standards.ieee.org, including detailed justification for the request, company contact information, and of compliance with relevant standards for proper usage in protocols like MAC addressing. Upon submission, applicants receive an with a , and the application remains valid for 30 days; processing typically completes within 7 business days after fee payment, at which point the assigned block details are provided via , with listings updated daily. Fees for assignments vary by block type and registration option, with a publicly registered MA-L (MAC Address Block Large)—which includes a full 24-bit OUI supporting up to 2^{24} unique addresses—costing US $3,480 as of 2025, plus an optional one-time US $200 fee for customized terms and an annual US $4,020 renewal fee for confidential listings that withhold company details from public view. Payment options include major credit cards, checks, or wire transfers in US dollars only. To mitigate address space exhaustion amid growing device proliferation, the IEEE RA introduced tiered block sizes in the , including the MA-S (MAC Address Block Small), a 36-bit identifier providing smaller EUI-48 and EUI-64 sub-blocks at a one-time of $880 for public registration, with organizations required to demonstrate 95% utilization of prior assignments via a formal letter before requesting additional blocks. Similarly, the MA-M (Medium) option offers 28-bit blocks at intermediate costs, such as an annual confidentiality renewal of $2,640. These alternatives promote conservation while maintaining uniqueness. Assignments are granted perpetually to support long-term organizational needs but remain revocable by the IEEE RA in cases of misuse, non-compliance, or failure to adhere to usage guidelines; post-assignment changes, such as company name updates, require separate forms and supporting documentation like press releases. Sustainability policies, including efficient block allocation and extended identifier guidelines, are outlined in guidelines to ensure ongoing viability of the global identifier ecosystem.

Structure and Format

Basic Composition and Length Variants

The Organizationally Unique Identifier (OUI) is fundamentally a 24-bit value, consisting of three octets that provide a globally unique designation for an organization, vendor, or manufacturer. This identifier forms the organization field within the addressing architecture, serving as the prefix for constructing various extended unique identifiers. In its standard form, the OUI lacks fixed subfields beyond its overall 24-bit length, though the most significant octet includes specific bits for administration: the second-least significant bit (U/L bit) is set to 0 to indicate universal (globally unique) administration by the IEEE, distinguishing it from locally administered identifiers like Company IDs where this bit is 1, and the least significant bit (I/G bit, also known as the bit) is typically 0 for addresses. The total for OUIs is 224=16,777,2162^{24} = 16,777,216 possible values, allocated by the IEEE to ensure uniqueness without inherent hierarchical structure. A representative example is the OUI 00-1B-44, assigned to a specific and often displayed in format as six digits separated by hyphens. Length variants of the OUI extend beyond the base 24 bits to accommodate different allocation needs while maintaining compatibility. The 28-bit variant, known as MAC Addresses-Medium (MA-M) or OUI-28, adds four bits to the standard OUI, allowing organizations to derive larger blocks of identifiers (up to 2202^{20} EUI-48s or 2362^{36} EUI-64s per assignment) for medium-scale needs, with the extra bits forming an Individual Allocation Block (IAB) prefix. Further extensions include the 36-bit OUI-36 (or MA-S), which appends 12 bits to the 24-bit OUI for smaller, specialized assignments, though the original IAB (also 36 bits) has been deprecated in favor of these structured variants. In practice, these OUIs serve as the most significant bits in combined 48-bit or 64-bit formats, such as EUI-48 and EUI-64, where additional bits follow for device-specific , and flags like the U/L bit may be modified in extended contexts to indicate local administration.

Hexadecimal and Canonical Representations

The Organizationally Unique Identifier (OUI) is represented in notation as a fixed-length string of six digits, corresponding to its three octets. This format ensures uniformity, with leading zeros added as padding if the value has fewer than six digits; for instance, an OUI value of 1B44 is padded to 001B44. digits are case-insensitive, though uppercase is the conventional choice in technical documentation and standards to avoid ambiguity in string comparisons. The preferred canonical format for textual display of an OUI, as specified by IEEE guidelines, separates the three pairs of hexadecimal digits with hyphens in the pattern XX-XX-XX. This hyphen-separated representation, such as 00-10-A4, improves readability in logs, configuration files, and human-facing documentation while maintaining the standard octet grouping. The IEEE explicitly endorses this format alongside the unpunctuated six-digit string for OUI listings and assignments. To derive the hexadecimal representation from the OUI's binary form, the 24 bits are divided into six groups of four bits, with each group converted to its corresponding digit using standard binary-to-hex mapping (e.g., 0000 to 0, 1111 to F). This process treats the octets sequentially without applying any byte or bit reordering, as the static textual form does not incorporate transmission-specific considerations. These representation conventions are formally defined in IEEE Std 802-2001, which establishes the string as the standard for OUIs in networking contexts. Subsequent revisions to the standards, such as IEEE Std 802-2014 and IEEE Std 802-2024, have refined these guidelines to promote consistency across protocols and implementations without altering the core format.

Formatting Conventions

Significance and Transmission Orders

The significance order for Organizationally Unique Identifiers (OUIs) employs a big-endian convention, with the most significant octet positioned first and bits within each octet interpreted starting from the most significant bit. This ordering facilitates human-readable representations, where OUI values are written from left to right (e.g., AC-DE-48), enabling direct logical comparisons as numerical values without requiring byte reversal. For transmission over networks, OUIs are serialized by octets in ascending order, beginning with octet 0, and embedded within larger identifiers like MAC addresses in Ethernet frames. Within each octet, bits are transmitted least significant bit (LSB) first, adhering to the data-communications convention outlined in IEEE Std 802.3. This LSB-first bit ordering ensures that the physical bit stream on the wire aligns with standard Ethernet encoding, where the first bit sent from an octet corresponds to its LSB. These dual ordering conventions—big-endian for significance and LSB-first for transmission within octets—promote reliable and in diverse systems. For instance, an OUI represented in canonical as 00-01-02 (octets: 00000000 binary, 00000001 binary, 00000010 binary) transmits as a bit stream starting with the all-zero bits of the first octet, followed by the LSB (1) of the second octet then its remaining zeros, and similarly for the third octet's LSB (0) followed by 000001. Such consistency is explicitly specified in IEEE Std 802-2014 to mitigate interpretation errors in multi-vendor networking environments.

Noncanonical Formats and Bit-Reversal

Noncanonical representations of organizationally unique identifiers (OUIs) deviate from the IEEE-recommended canonical format, which uses hyphen-separated pairs in transmission bit order with the least significant bit first. These alternative formats include colon-separated pairs (e.g., XX:XX:XX) or continuous strings without separators (e.g., XXXXXX), often appearing in software implementations or legacy documentation for brevity. However, the IEEE discourages such notations, as they can lead to ambiguity in parsing and do not align with the standardized hyphen-separated specified in IEEE Std 802-2014. In particular, colon-separated formats are sometimes associated with bit-reversed representations, where the colon serves as a visual indicator of the non-standard bit ordering, though this convention is not universally enforced. For instance, software tools or configuration files may display OUIs in this manner to distinguish them from equivalents, but issues arise if systems misinterpret the separator as altering the underlying bit structure. The T10 committee has noted that while no-separator formats simplify storage in some contexts, they violate IEEE guidelines for clear representation in standards like FC-PH and SPC-2. Bit-reversed representations invert the bit order within each octet of the OUI, a practice originating from the transmission conventions in networks under IEEE 802.5. This format, also known as the most significant bit (MSB)-first or noncanonical form, was used to accommodate the wire transmission order in and FDDI environments, where bits are sent MSB-first, contrasting with the least significant bit (LSB)-first canonical order in Ethernet (). As a legacy from IBM's implementation, it requires explicit conversion for cross-network compatibility, and while has been largely phased out, the format persists in for historical interoperability. The conversion process involves reversing the bits in each individual octet of the canonical OUI. For an octet value nn with bits b0b_0 (LSB) to b7b_7 (MSB), the reversed octet is calculated as ∑i=07bi⋅27−i\sum_{i=0}^{7} b_i \cdot 2^{7-i}. For example, the canonical OUI AC-DE-48 (binary octets 10101100, 11011110, 01001000) becomes 35-7B-12 in bit-reversed form (00110101, 01111011, 00010010). This per-octet reversal ensures the displayed hexadecimal values reflect the transmitted bit sequence on the wire without altering the byte order. Such bit-reversed OUIs were integral to IEEE 802.5 addressing, where MAC addresses incorporating the OUI followed this convention to match the network's MSB-first transmission. Bridges between and Ethernet networks perform this reversal on-the-fly to maintain address uniqueness, as detailed in DECnet specifications for Phase IV interoperability. RFC 7042 references these legacy considerations in IETF protocols to support assignment and usage of IEEE parameters, ensuring that bit-reversed formats do not conflict with modern OUI allocations.

Risks of Confusion in Specific Networks

In Token Ring networks, the use of non-canonical bit ordering for MAC addresses, where bits within each octet are reversed compared to the canonical format used in Ethernet, can lead to significant risks of confusion during bridging operations. If addresses are not properly converted when passing through mixed Ethernet/Token Ring bridges, the Organizationally Unique Identifier (OUI) portion—the first three octets—may appear altered, resulting in erroneous vendor identification or frame misrouting. For instance, an OUI of 00-10-A4 in canonical form might be interpreted as 00-08-25 after bit reversal, potentially attributing the device to an incorrect manufacturer and disrupting network management tools that rely on OUI lookups. This issue was particularly prevalent in legacy environments during the 1990s, where improper bridge implementations caused interoperability failures in source-routed Token Ring frames. Beyond , other formatting variations introduce risks in diverse network tools and software. The choice between hyphen (-) and colon (:) separators in textual representations of OUIs and full MAC addresses can cause failures in automated , as some utilities expect one delimiter while receiving the other; for example, IEEE standards traditionally favor hyphens for forms, but IETF conventions and many modern tools use colons, leading to regex mismatches or invalid input errors in cross-platform applications. Additionally, bit order mismatches—often mislabeled as issues—arise in software handling addresses from heterogeneous hardware, where little-endian systems might inadvertently swap octet bits without normalization, further obfuscating OUI recognition in diagnostic scripts or databases. These confusions have been noted in environments integrating legacy and contemporary protocols, amplifying errors in vendor attribution or lists. To mitigate these risks, IEEE guidelines, as outlined in the 802.1D-2004 bridging standard, mandate the use of canonical format for all interoperable representations, ensuring consistent bit ordering and transmission across LANs, including explicit handling for conversions in bridges. Modern network analysis tools, such as , automatically detect and normalize OUI formats regardless of input delimiters or bit orders, displaying addresses in a standardized colon-separated notation to prevent misinterpretation. This has addressed historical challenges since the 1990s, promoting reliable OUI-based operations in mixed-network deployments.

Types of Identifiers

48-Bit Identifiers (MAC-48 and EUI-48)

The 48-bit identifiers, known as MAC-48 and EUI-48, serve as fundamental addressing mechanisms in networking protocols, particularly within the family of standards for local and metropolitan area networks. MAC-48 refers to the original 48-bit media access control address format historically used for identifying network interface controllers (NICs) in technologies such as Ethernet () and Wi-Fi (). In this format, the first 24 bits consist of the organizationally unique identifier (OUI) assigned by the , while the remaining 24 bits are manufacturer-assigned to uniquely identify individual devices or interfaces within the organization's namespace. This structure allows each OUI holder to support up to 2^{24} (approximately 16.8 million) unique 48-bit addresses, enabling scalable device identification in local networks. EUI-48 represents the modern, preferred nomenclature for the same 48-bit identifier, emphasizing its role as an extended beyond just MAC contexts. The IEEE has deemed the term MAC-48 obsolete due to historical confusion over its precise scope, now standardizing EUI-48 for both hardware addresses and other protocol identifiers in applications. A key structural element in EUI-48 is the universal/local (U/L) bit, located at the second least significant bit of the first octet (bit position 1, counting from 0 as the least significant). For globally unique identifiers administered by the IEEE, this U/L bit is set to 0, distinguishing them from locally administered addresses (U/L=1) that may be assigned by network administrators without OUI involvement. These 48-bit identifiers remain integral to core networking functions, such as frame delivery in Ethernet and NICs, where the OUI ensures vendor uniqueness and the device-specific portion provides endpoint differentiation. Although the IEEE has restricted new high-volume applications of EUI-48 since 2000, recommending EUI-64 for broader scalability in emerging standards, EUI-48 continues to be widely deployed in legacy and current infrastructure as of 2025 due to its entrenched role in protocols. The IETF has similarly noted EUI-48's ongoing utility in protocols like IPv4 and VRRP, while advising caution in derivations like EUI-48 to EUI-64 mappings to avoid address collisions.

Extended Identifiers (EUI-64 and EUI-60)

The Extended Unique Identifier-64 (EUI-64) is a 64-bit globally standardized by the IEEE for use in network addressing and other applications requiring expanded address spaces. It consists of a 24-bit Organizationally Unique Identifier (OUI) in the first three octets, followed by a 16-bit identifier in the next two octets (typically set to 0xFFFE for interface identifiers), and concluding with a 24-bit device-specific or vendor-supplied portion in the remaining three octets. The universal/local (U/L) bit, which is the second-least significant bit in the first octet, is inverted in the Modified EUI-64 format used for . In the resulting identifier, a value of 1 denotes universal (global) scope, while 0 denotes local scope, preserving the original scope of the . To generate an EUI-64 from a 48-bit (such as MAC-48 or EUI-48) for stateless address autoconfiguration, the MAC address is split into its first 24 bits and last 24 bits, with 0xFFFE inserted in between, and the U/L bit in the first octet inverted. This process is formalized as follows, where MAC is represented in octets (0 to 5): EUI-64=(MAC[0:3]≪16∣0xFFFE∣MAC[3:6])\text{EUI-64} = \left( \text{MAC}[0:3] \ll 16 \mid 0xFFFE \mid \text{MAC}[3:6] \right) with the second-least significant bit of the first octet flipped (i.e., XOR with 0x02). The EUI-64 was mandated in RFC 4291 for forming the interface identifier in link-local addresses (prefixed with FE80::/10) and other addresses during autoconfiguration. Subsequent updates in RFC 8064 recommend against using the Modified EUI-64 format as the default for generating stable interface identifiers in stateless address autoconfiguration (SLAAC), due to concerns such as the exposure of stable hardware identifiers that enable device tracking across networks. Instead, RFC 8064 endorses RFC 7217's method for producing semantically opaque, stable identifiers that avoid embedding link-layer addresses. The EUI-60 is a deprecated 60-bit variant of the extended , formed by concatenating the 28-bit MA-M with a 32-bit extension identifier, primarily for legacy applications such as early standards. It was assignable via IEEE's MA-M (medium block) mechanism but is no longer recommended for new implementations, with EUI-64 preferred to conserve OUI space and ensure compatibility. In contexts, EUI-60 could underpin port names, though modern deployments favor EUI-64 for encapsulation.

Context-Dependent Identifiers (CDI-32 and CDI-40)

Context-Dependent Identifiers (CDIs) are shorter variants of organizationally unique identifiers designed for use in specific, limited scopes where full-length identifiers would impose unnecessary overhead. Unlike globally unique identifiers such as EUI-48 or EUI-64, CDIs derive their uniqueness from an assigned OUI combined with a manufacturer-specific extension, but their validity is restricted to a predefined context, such as a particular or protocol layer. This approach allows organizations to maintain identifier uniqueness within bounded environments while conserving bandwidth and storage in resource-constrained systems. The CDI-32 is a 32-bit identifier composed of a 24-bit OUI prefix, assigned by the , followed by an 8-bit extension identifier controlled by the OUI assignee. This structure ensures that the OUI portion provides organizational-level uniqueness across manufacturers, while the extension allows differentiation of devices or functions within the organization's products; however, the complete CDI-32 is only guaranteed to be unique within the context specified by the relevant standard or application. For representation, it is typically formatted as four bytes or a 32-bit numerical value, such as ACDE4823 derived from an OUI of AC-DE-48 and extension 23. Contexts for CDI-32 are often defined using arcs allocated by Working Groups, enabling precise scoping for applications like protocol elements or hardware variants. Similarly, the CDI-40 is a 40-bit identifier that incorporates a 24-bit OUI prefix with a 16-bit extension, or alternatively an Individual Address Block (IAB) base with a 4-bit extension in certain cases. The OUI-based variant, AC-DE-48-23-45 for example, follows the same of organizational uniqueness in the prefix, with the extension providing additional specificity, but the full identifier's applicability is confined to its designated context to avoid global collisions. Represented as five bytes, such as ACDE482345, CDI-40 supports slightly more granular identification than CDI-32 while remaining compact for transmission in low-overhead protocols. Like CDI-32, its context is delineated through standard-defined mechanisms, such as arcs, ensuring no overlap outside the intended scope. Both CDI-32 and CDI-40 were historically recommended for scenarios requiring abbreviated identifiers, such as in early or embedded systems standards, where the OUI guarantees no inter-organizational conflicts but the context bounds prevent broader reuse issues. Although effective for reducing in limited-scope , these formats have been deprecated in favor of more flexible extended unique identifiers for new designs, as they limit scalability beyond their defined boundaries.

Other Specialized Variants

In addition to standard extended unique identifiers, organizationally unique identifiers (OUIs) appear in specialized forms that prioritize organizational identification without full address extension. The 24-bit OUI alone serves as a pure identifier in protocols requiring vendor-specific recognition, such as in Subnetwork Access Protocol (SNAP) headers for organizationally unique protocol IDs or in voice VLAN configurations where telephony OUIs match the first 24 bits of MAC addresses from IP phones to assign them to dedicated VLANs. These applications leverage the OUI's global uniqueness for protocol extension or device classification without necessitating the full 48- or 64-bit structure. To conserve the finite 24-bit OUI space amid growing demand for unique identifiers, the IEEE Registration Authority introduced multi-address block variants in 2014, including MAC Address Block Large (MA-L) and MAC Address Block Small (MA-S). The MA-L corresponds to the traditional 24-bit OUI, granting assignees 2^{24} (approximately 16.8 million) EUI-48 identifiers and equivalent EUI-64 blocks for use in , device addresses, and other standards. In contrast, the MA-S employs a 36-bit prefix (formerly known as OUI-36), allocating 2^{12} (4,096) EUI-48 identifiers and 2^{28} EUI-64 blocks per assignment, enabling smaller-scale organizations to obtain unique blocks efficiently without consuming a full OUI. These variants support the same applications as full OUIs but facilitate finer-grained allocation to extend the viability of the global . Deprecated variants include the OUI-36, which was phased out in favor of MA-S effective January 1, 2014, though existing assignments remain valid for legacy uses in standards like certain IEEE 802 extensions. Similarly, the Extended Unique Identifier-60 (EUI-60) format, primarily derivable from MA-M, has been obsoleted to streamline assignments toward EUI-48 and EUI-64. The IEEE continues to promote MA-L and MA-S through guidelines in IEEE Std 802c-2017, emphasizing their role in sustainable identifier management amid projections of OUI space lasting until around 2100 under current usage trends.

Applications and Extensions

OUI-based locally administered addresses mechanism

The OUI-based locally administered address mechanism refers to a 24-bit identifier space derived from an organization's assigned Organizationally Unique Identifier (OUI) by modifying the Universal/Local (U/L) bit, specifically the second least significant bit of the first octet, to 1, which designates locally administered addresses. This modification transforms the global OUI into a prefix for local use, enabling the organization to generate up to 2242^{24} unique local addresses within that block, as the U/L bit is fixed and the remaining bits in the prefix and identifier field are utilized for assignment. The resulting block ensures separation from globally unique addresses, as the U/L bit value of 1 places it outside the scope of IEEE-assigned universal identifiers. In this mechanism, the organization assumes responsibility for assigning identifiers within this space, without any guarantee of global uniqueness beyond the local network or system scope. These addresses are typically employed for scenarios such as virtual network interfaces, where physical hardware constraints do not apply, or for testing environments that require multiple distinct identifiers without procuring additional global assignments. The process begins with the organization's OUI, followed by flipping the U/L bit to 1, after which the 24-bit local identifier is appended to complete the address; this approach maintains organizational traceability while adhering to local administration rules. The structure of an OUI-based locally administered address consists of the modified OUI prefix (with the U/L bit set to 1) combined with a 24-bit locally assigned identifier, forming a complete 48-bit suitable for individual use. This design prevents collisions with global OUIs, as the altered U/L bit shifts the prefix into the locally administered range, which is reserved for non-universal scopes and not overlapping with IEEE's global registry. By leveraging the existing OUI in this manner, organizations avoid the need for additional registrations while supporting scalable local deployments. This mechanism is formally specified in IEEE Std 802c-2017, which outlines the use of the U/L bit for distinguishing administration scopes in local and networks. As of 2025, the approach remains essential in and (VPN) environments, where virtual machines and tunneled interfaces demand numerous non-conflicting local addresses to manage scalability and isolation without exhausting global OUI allocations.

Encapsulation Methods

Encapsulation of Organizationally Unique Identifiers (OUIs) involves embedding the 24-bit OUI into larger identifier structures to create globally unique names or addresses, typically by prefixing the OUI to vendor-specific payloads. This technique is commonly employed in protocols such as the Name Assignment Authority (NAA) format used in (FC) and FC-NVMe, where the OUI serves as the initial bytes to ensure organizational uniqueness within extended identifiers. In NAA formats, such as the IEEE Registered (NAA 5h) or IEEE Extended (NAA 2h), the OUI (also referred to as the IEEE Company ID) occupies the first three bytes, followed by vendor-assigned data, forming 8-byte port names for initiators and targets in storage environments. Similarly, in Storage Management Initiative - Specification (SMI-S), OUIs are incorporated into Common Information Model (CIM)-based identifiers for managed elements in storage networks, prefixing payloads to maintain hierarchical naming consistency across devices. The primary method for encapsulation is , where the OUI is directly appended with a subtype field and subsequent data . The subtype, often a single byte or , defines the internal structure of the remaining bits, allowing organizations to subdivide their assigned space for specific applications like port addressing or device serialization. This approach ensures hierarchical uniqueness: the OUI guarantees global distinction at the organizational level, while the subtype and provide local uniqueness within that scope, preventing collisions in distributed systems. For instance, in extended NAA formats like NAA 6h (16 bytes), the OUI is prefixed to 13 bytes of vendor-specific extension, supporting longer identifiers for complex storage topologies. IEEE Registration Authority (RegAuth) guidelines, outlined in IEEE Std 802c-2017, standardize encapsulation for identifiers exceeding 48 bits, such as 64-bit EUI-64 or 128-bit formats, by recommending OUI prefixing to enable scalable, unique assignments. These guidelines emphasize bit-level alignment and reservation of the second OUI for administrative subfields to facilitate in non-LAN contexts. In storage networking, INCITS T11 standards have utilized OUI encapsulation since the early to extend OUI utility beyond local area networks, integrating it into FC frame headers and NVMe-over-FC mappings for reliable, vendor-unique addressing in SANs.

Encapsulation Examples and NAA Integration

One prominent example of OUI encapsulation occurs in autoconfiguration, where the 24-bit OUI forms the prefix of the 64-bit Extended Unique Identifier (EUI-64) interface identifier derived from a 48-bit . The process involves splitting the into its 24-bit OUI and 24-bit device-specific portion, inserting the fixed sequence FF:FE between them to extend it to 64 bits, and flipping the universal/local (U/L) bit in the first octet, which sets it to 1 in the EUI-64 to indicate a locally administered identifier. This encapsulation ensures the OUI uniquely identifies the vendor within the space, as specified in the addressing architecture. In networks, OUIs are encapsulated within World Wide Names (WWNs) using Network Address Authority (NAA) formats to create globally unique and node identifiers. For instance, in NAA format 2 (IEEE Registered), the structure begins with an 8-bit NAA type field set to 0x02, followed by the 24-bit OUI, and concludes with a 36-bit vendor-specific identifier, forming a 64-bit WWN such as 20:00:00:xx:xx:xx:yy:yy:yy:yy:yy:yy where xx:xx:xx is the OUI. This approach allows vendors to leverage their assigned OUI for scalable, unique addressing in storage area networks. The general NAA Name_Identifier structure standardizes OUI integration across protocols, comprising an 8-bit NAA type (e.g., 0x02 for IEEE OUI-based formats), the 24-bit OUI, and a variable-length for additional uniqueness. This [NAA][OUI][Payload] format supports in environments requiring persistent identifiers, such as storage fabrics. A practical is Cisco's implementation in NX-OS for virtual (vFC) interfaces in FCoE environments, where the switch's registered OUI is encapsulated into 64-bit virtual WWNs to assign unique identifiers to virtual host bus adapters (vHBAs). During configuration, administrators can specify or verify the OUI (e.g., via the "wwn oui" command) to generate WWNs in NAA format, ensuring fabric login (FLOGI) and compatibility without conflicts. This encapsulation maintains vendor traceability in virtualized data centers. These encapsulation practices, including NAA integration, are formally defined in the Framing and Signaling-4 (FC-FS-4) standard released in 2016 (INCITS 488-2016), which outlines WWN formats and mappings.

References

  1. https://standards.ieee.org/faqs/regauth/
  2. https://www.dell.com/support/kbdoc/en-us/000067530/what-is-an-organization-unique-identifier-o-u-i
  3. https://standards.ieee.org/products-programs/regauth/oui/
  4. https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf
  5. https://standards.ieee.org/products-programs/regauth/
  6. https://standards.ieee.org/products-programs/regauth/oui36/
  7. https://standards-support.ieee.org/hc/en-us/articles/25905648046868-Registration-Authority-Payments
  8. https://standards.ieee.org/products-programs/regauth/oui28/
  9. https://standards.ieee.org/products-programs/regauth/infocx/
  10. https://datatracker.ietf.org/doc/html/draft-ieee-rac-oui-restructuring-00
  11. https://ieeexplore.ieee.org/document/984782
  12. https://grouper.ieee.org/groups/802/3/interp/interp-1-0703.pdf
  13. https://www.ieee802.org/1/files/public/docs2020/yangsters-smansfield-mac-address-format-0420-v01.pdf
  14. https://www.t10.org/ftp/t10/document.98/98-186r0.pdf
  15. https://www.ieee802.org/secmail/pdfocSP2xXA6d.pdf
  16. https://datatracker.ietf.org/doc/html/rfc7042
  17. http://ftpmirror.your.org/pub/misc/bitsavers/pdf/dec/decnet/phase_IV/EK-DNAP4-TR-001_DECnet_Phase_IV_Token_Ring_Link_and_Node_Functional_Specification_199207.pdf
  18. https://www.ibm.com/docs/en/csfdcd/7.1.0?topic=ls-bit-ordering-in-mac-addresses
  19. https://standards.ieee.org/ieee/802.1D/3387/
  20. https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/macgrp.pdf
  21. https://www.wireshark.org/docs/wsug_html_chunked/ChAdvNameResolutionSection.html
  22. https://standards-support.ieee.org/hc/en-us/articles/4888705676564-Guidelines-for-Use-of-Extended-Unique-Identifier-EUI-Organizationally-Unique-Identifier-OUI-and-Company-ID-CID
  23. https://www.ieee802.org/secmail/msg00396.html
  24. https://datatracker.ietf.org/doc/html/rfc4291
  25. https://datatracker.ietf.org/doc/html/rfc8064
  26. https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/cdi32.pdf
  27. https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-small-business-200-series-smart-switches/smb2917-configure-telephony-organizationally-unique-identifiers-oui.html
  28. https://support.huawei.com/enterprise/en/doc/EDOC1100333370/eaf80a6e/understanding-voice-vlans
  29. https://www.ieee802.org/1/files/public/docs2017/802c-Marks-summary-0917-r1.pdf
  30. https://networkengineering.stackexchange.com/questions/743/mac-address-recycling
  31. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/vsphere-networking-7-0/mac-addresses/mac-address-generation.html
  32. https://www.t10.org/ftp/t10/document.06/06-002r2.pdf
  33. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/10_3_x/programming/smis/dcnm_smis_programming_guide_10_3_x.pdf
  34. https://www.rfc-editor.org/rfc/rfc4291.html
  35. https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/104x/configuration/fc-npv-fcoe-npv/cisco-nexus-9000-series-nx-os-fc-npv-and-fcoe-npv-configuration-guide-104x.pdf
  36. https://webstore.ansi.org/standards/incits/incits4882016
Add your contribution
Related Hubs
User Avatar
No comments yet.