Numeric Network Addresses

Note: This “Numeric Network Addresses” section is in a section related to numbers. For additional types of network addresses, see: network addresses which cover network names.

Network addresses are typically written out with a specific format, and in the case of numeric network addresses, these formats often help to identify a communications protocol that expected to be used to communicate with that network address. Examples:

[#ipv4addr]: IPv4 addresses

An IPv4 address takes up 32 bits (according to RFC 791: IPv4 pages 7 and 42). The most common form (also specified by RFC 791 pages 7 and 42) is two separate the address out into four fields/parts. Each field represents a fourth of the 32-bits, so each field is an octal byte (8 bits). Each field is a number ranging from 0 (zero) through 255. These fields are also most commonly separated by a period. This format of having four fields, separated by periods, has led to the term “dotted quad”.

An example of a dotted quad is “”. Most often, a dotted quad in this format (with numbers that don't exceed 255) refers to an IPv4 address. The most common exception to this are similar dotted quads which refer to a netmask that is meant to be bitmasked with an IPv4 address. (The most common example of such a netmask would be a “subnet mask”, most commonly starting with “255.255.255.”.)

Side note: A lot of software (most notably software that asks for a device's basic network configuration) may ask for a “subnet mask” by entering numbers into four fields. However, in most cases, the newer, modern, and preferred standard is to use CIDR notation to specify the prefix length. (For more clarity, see the details about CIDR notation.)


It does seem likely that the IPv4's protocol intended that each computer on the network could have its own network address. However, that idea seemed more valid when the Internet was still envisioned to be a network between universities and large organizations with budgets for exploratory technology. It probably seemed likely, at that time, that if the world was to ever embrace the concept of a worldwide computer network, that the worldwide network would be a new network that completely replaced the existing experimental network. After the time of some of these design decisions, the decision was made to allow this Internet to be directly used by more of the general public. Since the Internet grew beyond the initial expectations, the address space of the Internet became insufficient to keep providing IPv4 networks (especially of any reasonably requested size) to every organization that would be interested in one.

In the short term, one way to help with the impending address shortage was to use NAT (or, more specifically, PAT). This allowed addresses to be used much more conservatively. However, IPv6 is a nicer solution for providing more addresses.

Recognized uses for specific IPv4 addresses
[#ipv4priv]: Private addresses in IPv4

The term “private” here really means the same thing as “locally administered”. This basically means that an organization can make their own decisions regarding how to internally use the addresses, and such decisions should not cause a conflict with any other publicly-accessible IP addresses. (This is different from a “public” address. With many of the public addresses, attempts to utilize a “public” address could cause a public IP address conflict, disrupting people's ability to communicate with whoever is authorized to use that address.)

Private addresses are defined by IETF BCP 5: “Address Allocation for Private Internets”. Actually, knowing the related RFC number, RFC 1918, can be quite useful. The simple reason is that this is a fairly well-known RFC number. (This is probably the most well-known RFC number.) This RFC number does get used by firewall documentation. This is because RFC 1918 (“Address Allocation for Private Internets”) is often referred to by the industry, such as being seen in official documentation of network products. One example is the manual page for the /etc/pf.conf file used by OpenBSD's pf. Additionally, (other) online documentation by that firewall mentions RFC 1918. Cisco documentation may also refer to these as “RFC 1918” addresses.

Because these addresses are used by training material (such as books written for schools, and manuals for people who may work with products), there is a fair amount of familiarity with these addresses. The term “nineteen-eighteen address” does (at least occasionally) actually get heard during verbal conversations about technology (including when a couple of people are conversing with each other, as well as presentations/seminars). So, if there is any single RFC number that is more commonly useful to memorize than any other RFC number, this one (1918) may be it.

The three address ranges are: the IPv4 10/8 address range and the 172.16/12 address range and the 192.168/6 address range.

For those who just seem to struggle with remembering the boundaries of the less-often-used 172.16/12 address range, some memorization tips are discussd in the section about the 172.16/12 address range. To be fair, though, the class A and class C private ranges probably are really a bit easier to instantly recognize by just noticing the values in the octets. (For info on classes: IPv4 classes.)

Commonly, a lot of equipment defaults to using 192.168/16 and, probably often for just that reason, that is the address range most commonly used by small organizations. Organizations using larger amounts of IPv4 addresses are often found using the the IPv4 10/8 address range. Except when there actually are huge amounts of addresses being used, there really is often no reason why one of these private address ranges must be used over any other different one. In fact, using the less frequently used address range may reduce the likelihood of eventual IPv4 address conflicts (such as when networks might merge to some extent, such as when one business buys out another business, or simply when a VPN is used to “combine” networks to some extent).

[#ip4tsnet]: IPv4 addresses reserved for documentation/examples

Some IPv4 addresses have been similarly reserved by IANA for this same sort of purpose: They are:

So, an IPv4 address is an example/documentation address when the numbers before the third period match one of those address ranges. For example, is an example/documentation address. is not from those groups of example/documentation addresses, because the numbers before the third periodo do not match. The optional leading zeros are typically chopped off, but in case they aren't, understand that is the same thing as, so that is also an example/documentation address.

An overview of some special-use addresses is at IETF BCP 153: Special Use IPv4 Addresses. For more details about other addresses, see: IPv4 address usage.

[#ipv6addr]: IPv6 addresses

Prior to officially being called IPv6, the concept of an Internet protocol to be a successor to IPv4 existed, and the name of the envisioned upcoming protocol was IPng, where “ng” was meant to imply the phrase “next generation”. However, unlike Microsoft's “Windows NT”, the name IPng was replaced. (In contrast, Microsoft released a product that was shipped with the name “Windows NT”. After Win2K and subsequent versions of Windows were shipped using primary names that did not include the phrase “Windows NT”, the term “NT” ironically started to commonly refer to old implementations of software technology. By adopting the term IPv6, that Internet protocol seems destined to largely avoid such a fate.)

Systematic way of generally identifying an IPv6 address

An IPv6 address has either seven colons, or a single pair of colons as well as up to five other colons which are not directly next to another colon. Each colon which is not part of a pair of colons is surrounded by one, two, three, or four hexadecimal digits on each side of the colon. The pair of colons is adjacent to at least one, and up to four hexadecimal digits on at least one side of the pair of colons, and (very) possibly on both sides of the colons. If there are zero hexadecimal digits before the colon then it is at the beginning of the address and if there are zero hexadecimal digits after the colon then it is at the end of the address.


Each IPv6 address is 128-bits. (This is discussed further in the “Uniqueness” section that comes just a bit after this text.)


RFC 4291: IPv6 Addressing Architecture, section 2.2: “Text Representation of Addresses” provides the three official rules. The first two “conventional forms” are well-known, and well supported by lots of IPv6-supporting software. The first form specifies that colons are inserted between the hexadecimal digits that represent each group of 16 bits out of the 128-bit addresses. The second rule notes that a single double-colon can represent multiple other colons, including any zero that would be replaced by those colons.

According to RFC 5952: “A Recommendation for IPv6 Address Text Representation”, section 4.2.2: “Handling One 16-Bit 0 Field”, the double-colon must not replace only a single zero. Microsoft Exchange has been known to enforce that recommendation (e.g. “Literally IPv6” article). However, RFC 5952 is titled “Recommendation”, which generally should not be viewed as pre-empting the standard. (Software should accept the variation, as noted by the “Literally IPv6” article which cites section 1.2.2 found on RFC 1122 (“Requirements for Internet Hosts”) page 12.)

There is a third “conventional form” noted by the official standard, which is RFC 4291: IPv6 Addressing Architecture, section 2.2: “Text Representation of Addresses”. In this third form, the last thirty two bits are not represented with hexadecimal numbers, but instead are shown using a dotted-quad similar to an IPv4 address. (An example shows the now-deprecated IPv4-Compatible Address, while another example shows using an IPv4-Mapped Addresses.) For the first ninety six bits, a colon is used after every set of 16 bits (up to a maximum of six colons). Despite being part of the official standard, this format seems to be skipped by more introductory guides than other formats, and is not supported by nearly as much standard. It is primarily being mentioned here as a recognition of the fact that it is considered a valid form, identified by the official IPv6 standard for addressing. (For now... do not be too surprised if an updated standards document decides to mark it as “deprecated”. Presumably this form was meant to ease transition to IPv6, but because is hasn't been widely used before IPv6 finally started gaining some more traction, it might be removed in an effort to stop referring to a format that looks like an embedded IPv4 address. If that happens, both the inclusion and the later exclusion of this standard would be driven by efforts to move people towards thinking more about using IPv6.)


There was some discussion of making IPv6 a protocol using 64-bit addresses (or perhaps 96-bit addresses). RFC 1715: The H Ratio for Address Assignment Efficiency starts off by stating, “A substantial part of the "IPng" debate was devoted to the choice of an address size.” (That article goes on to discuss some limits previously experienced with numeric addresses, such as the formats of phone numbers that have been used in multiple nations. The article states that “there is no question” ... “that 128 bits is” beyond sufficient.) Clearly more bits for the addresses would have helped, but some discussion was needed to figure out just how many bits should be used. A thirty-third bit would have allowed an Internet that had twice as many possible addresses as the existing 32-bit IPv4 Internet, and the thirty-fourth bit would permit a network twice as large as that. Even 64-bits would have represented a substantial increase in size, and allowed IPv6 to permit many, many more addresses than IPv4.

However, instead of 64-bits, the eventual official decision (that has become widely supported) ended up being an agreement to use 128-bit addresses. That doubles (and, therefore, exponentially increases) the number of addresses an additional 64 times compared to IPv4. (A single double would provide twice as many addresses as what the IPv4 Internet can provide. This doubled, and doubled again, and doubled again, for a total of 64 times that the address size was doubled.) This gigantic enlargement was done to intentionally make plenty of addresses. There are so many addresses available that the current plan is that each person will have more than 32-bits (which was the size of the entire IPv4 Internet). Unlike IPv4, the IPv6 standard has been designed to have enough addresses to easily afford massive address waste even on a worldwide scale.

  • If IPv6 used 64-bit addresses, there would have been 18,446,744,073,709,551,616 addresses. Instead, that is how many addresses are in each IPv6 /64 subnet.
  • Individual have often given a /48 subnet with 1,208,925,819,614,629,174,706,176 addresses. This is ofen used to be split into 65,536 groups of IPv6 /64 subnets.
  • The number of IPv6 addresses is 340,282,366,920,938,463,463,374,607,431,768,211,456 (three hundred forty undecillion, two hundred eighty-two decillion, three hundred sixty-six nonillion, nine hundred twenty octillion, nine hundred thirty-eight septillion, four hundred sixty-three sextillion, four hundred sixty-three quintillion, three hundred seventy-four quadrillion, six hundred seven trillion, four hundred thirty-one billion, seven hundred sixty-eight million, two hundred eleven thousand, four hundred fifty-six).

It would be natural for people trained in frugal assignments of IPv4 addresses, having been made well aware of historical waste and subsequent problems, to not want history to repeat itself. Such concerns are clearly addressed by RFC 3177 section 4.

One reason for the decision to give out so many addresses is that the people designing the IPv6 standards wanted addresses to be heavily used. There is benefit perceived in having people use many addresses. If people use many addresses early, this may help researchers to be able to better see what does work well and what does not work well. That information may help policy makers to be able to make more informed decisions. If problems are learned early, perhaps a re-design can be implemented earlier, and that may affect more addresses than if the fix gets designed later. So, unnecessarily conserving IPv6 addresses may actually cause more harm than good (unlike the IPv4 network, which was designed in a different way). People are encouraged to go ahead and heavily use (or even waste) many IPv6 addresses.

Think of using IPv6 addresses like breathing air. In some movies that portray a disaster scenario (with potential tragedy), a person in a submarine or a space ship or an isolated cave may follow some advice to remain calm and breathe slowly, because that will use up less air. This is because air may be a limited, and therefore a precious, resource, and breathing slower will use up less air. Taking actions to limit the usage of this precious resource makes sense.

Now, compare that to a person who is standing on solid ground where air is plentiful. If a person decides to breathe in and out very heavily and quickly many times in a row, then breathable oxygen-filled air is getting used up more quickly. Who cares? There's plenty around. Such a person may be ridiculed for making unnecessary noise, or perhaps risking hyperventilation and subsequent fainting (which may be, at the very least, embarrassing). However, what is not likely to happen is that people will criticize the person because they are using up the air too quickly. (If the person does get criticized, the reason for the criticism is not going to be because the air got used up.) As critically important as air is, there is an abundance. Perhaps a corporation could pollute air in a way that causes concern, but a single person's breathing is not going to meaningfully affect the amount of air in an area with many trees.

Similarly, there's no reason for people to be feeling particularly worried and cautious about using up an IPv6 address, or even millions of IPv6 addresses. There are *plenty* of them!

RFC 3177 (section 2) discusses splitting a 128-bit address into two segments of 64-bits. Section 4 discusses giving a /48 to each subscriber of Internet access. The specific recommendation of using a /48 for many scenarios was rescinded with RFC 6177. The logic used with RFC 6177 was simply being that “a one-size-fits-all approach is not necessary or appropriate.” However, the arguements given with RFC 3177 still apply. The RFC did say, “there seems to be little benefit in not giving a /48 if future growth is anticipated.”

RFC 3177 did note that in the future, people “will still have the option of imposing much more restrictive allocation policies on the remaining” large amount of unused addresses. It is a bit comforting to see that actually happened (when RFC 6177 was implemented), rather painlessly.

When IPv4 was designed, the plan was not initially to have that network be a worldwide network that was heavily used by the general population. When IPv4 did start getting used more widely, some design choices were changed, although people did try to not take resources away from people who were already given resources. The IPv6 design was made with a totally different plan in mind. It is was designed to have plenty of addresses.

Other info

See: RFC 4291: IPv6 Addressing Architecture, section 2.8: “A Node's Required Addresses”. It may be helpful to first review RFC 2460: “IPv6”, section 2: “Terminology”. RFC 4291 section 2.8 starts talking about just hosts, but then the later section notes, “A router is required to recognize all addresses that a host is required to recognize, plus” more addresses. So the first section does apply to all nodes.

Private addresses: the FD00::/8 range.

An overview of some special-use addresses is at RFC 5156. For more details about other addresses, see: IPv6 address usage.

[#eiuaddr]: EUI addresses
Common features
Organizationally Unique Identifier (“OUI”)

The first 24 bits are called an “OUI-24” (and have historically often been refered to simply as an “OUI”, just like a “MAC-48 address” has historically often been referred to simply as a “MAC address”). (Simple math: For an EUI-48 address, this represents the first half of the address.)

[#ouitwofr]: OUI-24

An eighth bit of 0 is Unicast, and 1 is multicast, per Graphic of MAC-48 address (hosted by Wikipedia) (which is a graphic used on Wikipedia's page for “MAC address” “Address details”).

This ends up meaning that Unicast addresses have a first byte which is even.

[#ouilaa]: Locally administered address (OUI)

With each OUI, the seventh bit of each MAC address (in the most commonly written form, canonical form) is called the “universally/locally administered address bit”. (This is documented by Wayback Machine @ archive of IEEE tutorial on MAC addresses. The diagram may confuse because it looks like the Universally/Locally administered address is the second bit. It is the second bit that is transmitted (since in Ethernet the bits get transmitted in non-canonical form), but it is the seventh, not the second, bit of the canonical MAC address. That Universally/Local Administratored address bit represents the seventh bit of the OUI AC-DE-48 as seen in the hexadecimal representation.)

That bit represents whether it is univeral or locally administered. This means that all MAC addresses that are universal (not local) should have a second digit of zero, one, four, five, eight, nine, C, or D. Otherwise, that bit is set to one, which indicates a “Locally Administered Address” (“LAA”).

If the “universally/locally administered address bit” bit is set to 0, then the assignment should be done by whoever used the OUI-24. (If the OUI-24 was assigned to the “IEEE Registration Authority”, it may be an IEEE IAB, so checking the IAB listings may provide more info on who made the assignment of the individual address.)

BinHexsecond-to last bitlast bit
of byte

(The above chart is for standard MAC-48 addresses. Modified EUI-64 flips the meaning of the value of the second to the last bit.)

(See also: LAA (MAC).)

Based on the above, a NIC (with a publicly/universally assigned Unicast address) is likely to use an OUI-24 that has a second (hexadecimal) digit of 0, four, eight, or C. This is largely represented by the public listing, although there may be some rare exceptions (11-00-AA and AA-00-?? addresses).

Good addresses to use for local assignments (for devices that will be communicating using Unicast, which is the most typical type of communications), are ones that have a second (hexadecimal) digit of 2, 6, A, or E.

More details

Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID) (PDF file from IEEE) mentions that the seventh bit is used as the locally administered address indicator. Actually, the referenced PDF file says, “The least and second least significant bits of Octet 0 are designated the M bit and X bit, respectively.” Earlier, it also talks a bit more about the X bit, which “locally administered address” indicator bit.

So, if the 7th bit is the X bit, then the 8th bit is the “M bit” according to that PDF document.

The document also says, “In the OUI, both the M and X bit have the value 0.”


Public listings: When an OUI is allocated for use by a specific organization, in most cases that organization is publicly identified. So, when a manufacturer is given an OUI to use, people can look up details to identify any public assignments. What this basically ends up meaning is that the OUI in a device's MAC-48/EUI-48 address can typically identify what company manufactured the network circuitry of that device.

The OUI for some listings (e.g. AC-DE-48) is listed as “PRIVATE” in the OUI listings. However, private OUI listings are the minority. (If the public listing is “IEEE Registration Authority”, one may also wish to check the IEEE IAB listings. See IAB for more info.)

Since IEEE assigns the allocations, the most authoritative list is likely the public OUI listing at

MAC address lookup sites

Coffer lookup of ACDE48 lists it as "IEEE Registration Authority. It has been used as example (e.g. does this. )

Others have also cropped up, including Arul John's MAC-48 lookup and WireShark OUI lookup.

[#iab]: Individual Address Block (by IEEE) (“IAB”)

An IEEE IAB is similar to an OUI-24, except that the first 12 bits are used by IEEE and are not available to the purchaser of the IAB. This allows the IEEE to subdivide a larger OUI-24 into smaller allocations called IABs. The costs for an OUI, IAB, or EtherType Field has noted an IAB's cost of $550, which is a third of the $1,650 price which was (and perhaps still is) the cost of an OUI-24. The maximum number of addresses that may be used within the 12 bits available to the purchasing organization is 4,096 addresses. Despite costing a full third of a OUI's price, the 4,096 addresses in an IAB is substantially smaller than a third of the number of addresses in a full 24-bit OUI, which is 16,777,216 addresses. So the cost per address is much higher (and so will be quite unattractive to an organization that will utilize many addresses), but the overall cost is lower.

The IABs that have been assigned may be viewed at IEEE's public IAB listing.

Other variations


22-bit OUI

IEEE Tutorial: Use of Extended Unique Identifier (“EUI”) and similar, archived in July 2010 by the Wayback Machine @ says “A variety of alternative context-dependent identifiers, such as specialized 22-bit OUI-based identifiers, have been used in the past. Such uses are deprecated; the CDI-32 or CDI-40 should be used in future applications requiring the use of compact context-dependent identifiers.” (Spacing altered from the quoted text.)

More information may be found at: IEEE Tutorial: “Examples of deprecated 22-bit OUI uses”, archived in July 2010 by the Wayback Machine @ says

[#euimac48]: EUI-48/MAC-48 address
Multiple names

Names include:

EUI-48 (48-bit “Extended Unique Identifier”)

In common practice (even if, by some technical definitions, this is not technically accurate) EUI-48 is simply a new name for what has previously been called a MAC-48. (For all the available details about the difference between EUI-48 and MAC-48, see the section about MAC-48.) There is another standard called EUI-64 which this term does sound closer to. However, many technicians have learned the term “MAC-48” (or, more likely, the older term “MAC”) for years, and so that term may be more familiar.

Converting an EUI-48 to an EUI-64

Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID) (PDF file from IEEE), page 15 says, “Mapping an EUI-48 to an EUI-64 is deprecated.”.

Then, the document goes on to describe how that was done in a standard fashion. Using the older standardized approach, an EUI-48 address could be converted to an EUI-64 (which, in fact, as the name may sufficiently imply, is 64 bits) by either inserting 0xFFFE after the OUI-24 and before the other bits (as shown by Wayback Machine @ archive of IEEE's EUI64 tutorial).

Some IEEE documentation may mention an option of using 0xFFFF instead of 0xFFFE. That is only for MAC addresses, and not “modified EUI-64 addresses”. RFC 7042 page 10 (in RFC 7042 section 2.2.1) clarifies, “The IETF uses only FF-FE to create Modified EUI-64 identifiers from 48-bit Ethernet station identifiers regardless of whether they are EUI-48 or MAC-48 local identifiers. EUI-48 and local MAC-48 identifiers are syntactically equivalent, and this doesn't cause any problems in practice.”

Following is some older text, although the referenced material at IEEE seems to have changed since this text was written:

To convert to EUI-64, see IEEE documentation (which may simply redirect to IEEE documentation in PDF format) which states to insert 0xFFFE after the OUI-24 of an “Encapsulated EUI-48 Value”. The same documentation shows that MAC addresses may also use 0xFFFF after the first 24 bits, but after converting the address from canonical to non-canonical format. Such a converted address becomes known as an “Encapsulated MAC-48 Value”. This would suggest the difference between MAC-48 and EUI-48 may be whether the address is canonical. The section on MAC-48 indicates a different, even less impactful, distinction.

Although IEEE may not officially agree with this as an officially accepted practice, treating an EUI-48 as a MAC-48 would likely cause no problems in many cases (even most cases... and really, probably all practical cases). When there was ever any meaningful distinction between an EUI-48 and a MAC-48 (if there ever really was one), Wikipedia's section of the addressing details of MAC addresses notes that these two separate types of addresses were “assigned from the same numbering space.” (For further details about MAC-48 addresses and/or the difference between MAC-48 and EUI-48, see the section about MAC-48.) From the documentation about converting to EUI-64, it appears the simple difference had to do with EUI-48 being canonical format, and MAC-48 being non-canonical format. This ends up being more of a matter of notation than unique addressing, as described by the section about EUI addressing: canonical format.

[#macfrdoz]: MAC-48

A more modern name than the term “MAC address”. This clearly communicates the bit length. (This doesn't mean to suggest that older implementations had different bit lengths. However, it is considered a standard acronym. When teaching people about this technology, this more informative acronym is nice to repeatedly use, because it probably helps people learn how many bits are in the address.)

A MAC address is 48-bits and has also been known as a MAC-48, although the term “MAC-48” has since been considered obselete by the IEEE (according to a Wikipedia note about MAC-48).

A MAC-48 is “assigned from the same numbering space” and “syntantically indistinguishable” from an EUI-48 address (quoting Wikipedia's section of addressing details for MAC addresses). Before MAC-48 was considered by the IEEE to be an obsolete term, the only real difference between a MAC-48 and an EUI-48 is that the numbers assigned by IEEE for use as MAC-48 addresses were meant to be “used for network hardware” (quoting section on Wikipedia (from April 10, 2010) of addressing details for MAC addresses), whereas the numbers assigned by IEEE for use as EUI-48 addresses were, “used to identify other devices” (which are not network hardware), “and software.” Of course what would a device need an EUI-48 for if it was not hardware capable of communicating on the network? (Perhaps what was meant is devices, like printers, which provide a primary purpose other than to help with the communication of network traffic.) So the difference between EUI-48 and MAC-48 is really unimpactful. The insignificant difference was significant enough to get a mention by RFC 4291 page 22, which references “the differences between IEEE MAC-48 and EUI-48 identifiers.” However, no technical changes were needed, because MAC-48 identifiers and EUI-48 identifiers were functionally equivilent.

The first three octet bytes of a MAC-48 are an OUI-24. The next 24 bits may be assigned by some hardware manufacturers “in nearly any manner they please, subject to the constraint of uniqueness.” (Quoting Wikipedia's article on MAC address.) (However, for smaller scale, an IEEE IAB may be used, in which case the address boundary restrictions of the IAB would be relevant.)

A MAC-48 address may be converted to an EUI-64 (which, the name may sufficiently imply, in fact is 64 bits) by flipping the second bit of the OUI, and then inserting 0xFFFE after the remaining bits from the OUI (and before the rest of the bits of the MAC-48).

Some documentation might suggest possibly using 0xFFFF instead of 0xFFFE. For instance, Wayback Machine @ archive of IEEE's EUI64 tutorial showed using 0xFFFF. However, the recommended practice is to treat the address as an EUI-48, and performing a similar process to convert the EUI-48 into an EUI-64 (by inserting 0xFFFE after the OUI-24). The usage of 0xFFFE instead of 0xFFFF is clearly specified by RFC 7042 page 10.


Media Access Control. This refers to the fact that this is the address used by the protocols that interact directly with the “media”, which is a term referring to the wiring for wired networks, and the equivilent resources (like airwaves) for other technologies (like Wi-Fi). Another example of media is the light beams used by IrDA.

(The term “Media Access Control” is also the name of the lower sublayer of the OSI Model's Layer 2: the Data Link Layer.)

See: MAC-48.

Burned-In Address. This refers to the idea that the MAC address is unique for every network card, and is written into ROM or some other not-often-written memory. However, newer cards typically do have the BIA written in some form of memory which is actually writable.
Ethernet Hardware Address. Perhaps the worst of the names that are available and (at least somewhat) widely used, because this type of address is also what would be used if a non-Ethernet network (such as the historic “Token Ring” standard) were to be used.
[#laamac48]: LAA (MAC)

LAA specificaly refers to a “Locally Administered Address”. This is a term that is used when someone other than the original manufacturer is assigning the address. (So, this is similar to the “private-use” IP addresses.) In theory, the “local administered” bit will be set to 1, which will cause the second hexadecimal digit to be a 2 or 6 or A or E. However, MAC address spoofing is possible (both by attackers, and by people who may have a legitimate purpose for wanting to use a specific MAC address that had previously been used).

See: LAA (OUI).

With the exception of LAA (possibly having the additional connotation/implication of being a “private” address), these terms effectively all have the same meaning, and may be used interchangably.

Further details, such as whatever trivial differences may exist between EUI-48 and MAC-48, may be covered by glossry entry: Media Access Control and/or glossary entry: EUI.


The first half of the address should follow the rules of OUI-24. (There are some patterns about OUI-24, and they also apply to the first bits of an EUI-48.)

EUI-48/MAC-48 addresses may be commonly referenced in a varitey of formats, such as six hyphen-separated pairs of hexadecimal digits (e.g. 0E-01-23-45-67-89) or six colon-separated pairs of hexadecimal digits (e.g. 0e:01:23:45:67:89) or, less commonly, three period-separated groups of four hexadecimal digits (e.g. Cisco devices are known to use a format like 0e01.2345.6789). Another format sometimes seen (especially when written directly on a card) is simply twelve hexadecimal digits, unseparated (e.g. 0e0123456789). Although the colon-separated variety has quite a bit of historical precedence, the hyphen-separated is the way it is reported by IEEE's OUI listing, and may be easier to distinguish from an IPv6 address. (The colon-separated notation is not a valid IPv6 address because there is not the correct number of colons: Fewer than seven colons in an IPv6 address requires two colons in a row, and that isn't seen in a MAC address. A MAC address written in the common format that uses colons will have only five colons.)

[#euicanon]: Canonical form
Comparing canonical form to non-canonical form: How to convert

To start off this conversation, consider a picture: a graphic identifying some bits in a MAC address. (This picture was converted and optimized. The original had been uploaded to Wikipedia by “Inductiveload”, as noted by Wikipedia's article on MAC-48_Address.svg, which is now a modified version of the graphic.)

Based on that picture, it appears that the seventh bit is used to determine whether the address is considered to be “globally unique (OUI enforced)” or “locally administered”. That is consistent with the section on OUI LAA documentation/Locally Administred MAC-48 Address documentation.

However, if seems that we may get a different story when looking at a graphic file from IEEE, Wayback Machine @ archive of Figure 1 from the IEEE tutorial on MAC addresses (which was used with documentation that came from IEEE, Wayback Machine @ archive of IEEE tutorial on MAC addresses).

It seems that this picture from IEEE shows the second bit is the “Universally/Locally Administered address bit”. Is Wikipedia's documentation wrong?

Actually, adding to the confusion: The graphic shows a “Hexadecimal Representation” of AC-DE-48-00-00-80. However, the “Binary Representation” shows “0011 0101  0111 1011  0001 0010  0000 0000  0000 0000  0000 0001”. Using Super-fast converting between binary and hexadecimal (or a slower method, if preferred), those first eight bits look like they should convert to “35” in hexadecimal, not “AC”. Was the author at IEEE just completely confused when creating the graphic?

The simple answers are: these are not outright errors (even if they may be a bit confusing).

In most cases, when writing numbers, the most significant numbers are written out first. Therefore, to display a value representing two hundred and one, the number is written as 201. The format may refer to “MSB format”, which refers to the “most significant bit(s)” (or, not really any different, the “most significant byte(s)”) being transmitted first. MAC addresses may sometimes (but not usually) be written out in this MSB form.

However, more often, MAC addresses tend to be displayed in what is called “canonical” form. The reason this matters is because sometimes non-canonical form may be used, while other times canonical form may be what gets used or referred to. So knowing which form is being used may matter in some cases (such as when viewing an unfiltered display of what bits get transmitted on a cable). Also, knowing how to convert between the two formats may be useful.

How to convert between canonical form and MSB form

To convert to or from canonical form, first split up the information (such as the bits of a MAC address) into octet bytes. Then take each byte, and convert from MSB to LSB or from LSB to MSB: in either case the process involves simply reversing the order of the bits within that byte. Understand that when there is more than one byte, the re-ordering of the bits is something that happens within each individual byte. As a quick reminder, bytes are commonly represented with a pair of hexadecimal digits (where each hexadecimal digit represents a nibble). So, first the bits of the first part of hexadecimal digits are reversed. Then, the bits of the next pair of hexadecimal digits are reversed. The order of the bytes themselves are not reversed; only the order of bits within each byte.

As an example used (and not clearly documented in what is happening) at IEEE's “Standard Group MAC Addresses Tutorial”, the example MAC address in canonical form is AC-DE-48-00-00-80. The direct conversion (inserting spaces so there is a space before and after each nibble) of AC-DE-48-00-00-80 results in the following binary number sequence:
1010 1100 - 1101 1110 - 0100 1000 - 0000 0000 - 0000 0000 - 1000 0000
To help match the binary and the hexadecimal in the above example, understand that the hexadecimal nibble E represents the fourth nibble, and so it represents the fourth set of numbers, 1110.

To convert the first byte of this example, 1010 1100, from MSB to LSB format, the first eight bits are written out in reverse order. What was first becomes last, and what was last becomes first. So the result is 0011 0101. Next, after converting the first byte, the second byte becomes converted, resulting in the second converted byte looking like 0111 1011. After the bits of the third byte are written in reverse order, the third byte looks like 0001 0010. The fourth and fifth bytes look identical after writing their bits out in reverse order. The final byte is converted from 0000 0001 to 1000 0000. The end result string, after conversion, is 0011 0101 - 0111 1011 - 0001 0010 - 0000 0000 - 0000 0000 - 0000 0001. Now that all the bytes have had the order of their bits reversed (even though the position of each byte is unchanged), the result converted back to hexadecimal looks like: 35-7B-12-00-00-01. Both the original text AC-DE-48-00-00-80 and the converted text 35-7B-12-00-00-01 may be referring to a single NIC using a single MAC address, where one of these strings represents canonical LSB format and the other represents non-canonical MSB format.

Reviewing/Analyzing the results of the conversion

Both AC-DE-48-00-00-80 and 35-7B-12-00-00-01 may represent the exact same address, simply written out differently. (As an analogy for English speakers: “twelve”, “12”, and “dozen” may all be different ways to write out the same value.) So, if there is a possibility of addresses being represented in both forms, then knowing which form is being used may be needed to properly understand what address is actually being used.

With enough thought, study, and/or familiarity, one can see that the post-converted number has the same amount of bits set to one as the pre-converted number. As most easily seen in the example (by viewing the final bit that is set to one), the twelth nibble of the pre-converted number will have the same amount of bits set to one as the eleventh nibble of the post-converted number. The amount of bits with a value set to one (instead of being cleared to zero) in the pre-converted number will affect the opposite nibble of the same byte in the post-converted number. The numbers within any specific byte of the pre-converted number do not affect the numbers of other bytes in the post-converted number.

Note: IEEE's Figure1.jpg from the MAC tutorial is actually a Windows bitmap file, despite the filename. This (and a converted file) has been archived locally at ../netaddrf/ The graphic from Wikipedia is Mac-48_Address.svg (hosted by Wikiepdia) and is

When canonical and non-canonical formats get used

Interpreting the bits on a wire (or reading IEEE documentation which shows the bits on a wire) or interpreting bits from the hardware address on the card, and trying to compare that non-canonical address to a displayed/printed canonical address, could lead to some confusion. For most end users, there is only one specific format that is most commonly used, so this ends up being a non-issue. However, if and whenever performing an activity where the formatting of being canonical or non-canonical may be an issue, at least knowing about the issue can be helpful.

Non-canonical (“MSB” ordering) represents the address on the card. The first bit of non-canonical represents what goes over the LAN. MSB is also more intuitive (the first digit, which is a bit, is the “most significant”).

So, why would canonical (which uses intra-byte “LSB”) ever be used? One reason, which may be among the most important, is the end user experience. As inconvenient as dealing with the whole “MSB or LSB” issue may be, end users may see a canonical MAC address written on the card. Ideally, what the end users see on the card should generally match what the software reports. Also, many pieces of software will typically use canonical addresses. Confusion may be lessed if a user sees a canonical address and then reboots to another operating system and then sees the same address, instead of a different address. Therefore, programmers should be careful to be reporting the canonical MAC address when displaying a MAC address. RFC 2469: Caution (regarding canonical bit ordering) notes, “In most cases, such fields must be in” canonical form. So, the simple reason why canonical form must frequently be used is just because, as a standard, it is what actually gets used.

Ethernet tends to transmit the bits of a byte in canonical form. (This means that Ethernet tends to transmit in least-significant-bit order compared to how the bits are stored in MSB order in memory, and so those bits are sent over Ethernet in the reverse of the order of those bits in memory.)

Canonical represents, as a standard (or at least common practice), how the address gets stored in memory. However, the computer realizes that all bits in memory are going to be sent in reverse order. Therefore, when the addresses are transmitted/received over the wire or obtained from the card, the addresses get reversed and a conversion between canonical and non-canonical order happens.

Going back to an example of non-canonical form again: Hardware manufacturers take the OUI that is typically published in canonical format, and convert it to a non-canonical address when they store the address in the card. (The address on the card does not contain the card's canonical MAC address. It contains the results of converting the canonical MAC/EUI-64 address into another address, which is stored in non-canonical format.) When getting the actual address that is reported by the card, programmers should be careful to make sure that the address read from the card is converted to a canonical address before the address gets displayed to an end user.

As a re-hash contrasting canonical and non-canonical: The order that the bytes themselves are still sent over Ethernet in the same order. This means that the order of the bytes is not reversed, and does not change in any way. Therefore, if a non-canonical address of 82-FF-FF-FF-FF-FF was sent, the first four bits sent would be 0100 (which represents the digit 2, but with the least significant bit first) and the second eight bits would be 0001 (to represent the number eight with bits sent in LSB order). Out of the 48 bits of a typical EUI-48 MAC address, it is the eigth bit of a canonical address that will get sent over the LAN first when LSB transmission order, like Ethernet, is used.

This is elaborated upon with RFC 2469: Caution (regarding canionical bit ordering).


Wikipedia's article on “MAC Address”: section called “Address details” states, “The IEEE expects the MAC-48 space to be exhausted no sooner than the year 2100;”, and (at the time of this writing) cites an IEEE PDF document which does not seem to mention the year 2100.


In theory, every NIC should have a unique MAC address. In practice, that may not be true. First, the MAC address communicated over the network is determined software. Customizing the MAC address used by the operating system's network stack is generally simple in Unix, and may also be done with several drivers for network cards in Microsoft Windows. Second, the MAC address of software is generally determined by what is on the card. Even early physical network cards could often be manually re-assigned. Third, with the advance of virtualization, virtual machines may frequently end up creating MAC addresses that are not in any way centrally monitored. Finally, there are cases where the same physical MAC address may be used by multiple NICs that come out of some factories. This probably is not supposed to be the case, and known instances of this may be fairly rare, but they do exist. One example is shown by a photo of two APC UPS AP9631 NMCs using MAC 00C0B7C477F1. A well known speaker related to IPv6 networking has also made the comment that HP servers (perhaps especially refurbished ones?) are known to sometimes have re-used MAC addresses. Duplicate MAC addresses causing problems are so uncommon that technicians generally do not check for duplicate MACs as new NICs are used. The rarity of detected problems may be helped by the fact that duplicate MAC addresses typically won't typically be mattering for devices that are not on the same subnet. However, know that even if they shouldn't exist, they could.

Care should be taken when creating virtual devices to ensure that MAC addresses are unique. Virtual machine software, such as Qemu, might often default to using a specific initial MAC address when a virtual machine is created. This could lead to a higher chance of MAC address conflicts than what is commonly seen with physical equipment. (Such an issue is likely quite easy to remedy, once the issue has been identified. It may involve shutting down (virtual) equipment, as the virtual hardware's change may need the system to restart. However, it is possible that a temporary change (effective until the system is restarted) might be possible: see spoofing/setting a custom MAC address.

[#macspoof]: “spoofing”/setting a custom MAC address

MAC addresses are considered easy/trivial to change. It can often be done (at least temporarily) using just the software that is bundled in with modern operating systems. Therefore, MAC-based security options are not considered to be strong security. Changing a MAC address is often known as “spoofing” the MAC address. Details on how to do this are at: manually setting a network address.

[#arpndp]: How to determine MAC addresses (at different networking layers)
[#nabormac]: Neighbor (NDP for IPv6, or ARP for IPv4) cache (of MAC-48 addresses)

For IPv4 addresses, use “ arp -a ”. (The exact same command can be typed in Microsoft Windows, and the result will be essentially the same.)

Microsoft Windows

For IPv4 addresses, use “ arp -a ”. (The exact same command can be typed in Unix, and the result will be essentially the same.)

ARP for IPv4
Regular ARP

If a computer system has an IPv4 address of another machine, the “Address Resolution Protocol” (“ARP”) may be used to attempt to determine the remote system's MAC-48. If the remote system supports the common implementations of TCP/IPv4 over protocol that uses OSI Model Layer 2 (e.g. Ethernet), and if the remote system is in the same subnet as the system making the query, such as ARP query should typically work. Otherwise, any communication to that device is expected to fail.

[#inarp]: Inverse ARP
Technology for other purposes

Different than RARP. Not to be confused with Reverse ARP (“RARP”).

The purpose of RARP, like BOOTP and DHCP, is for a computer to be able to obtain its own IPv4 address. In contrast, InARP is about a (functional) computer obtaining the IPv4 address of a different device. The concepts may be a bit similar, but are not absolutely identical, and these are different protocols.

However, this might not be as useful as hoped by people with a known MAC address. The RFC for InArp is RFC 2390: Inverse ARP (“InARP”). RFC 2390: Inverse ARP (“InARP”) section 5: “Motivation” states, “The motivation for the development of Inverse ARP is a result of the desire to make dynamic address resolution within Frame Relay both possible and efficient.”

MCSA/MCSE Implementing, Managing, and Maintaining a Microsoft Windows Server 2003 Network Infrastructure (book published by Syngress) says, “On nonbroadcast-based multiple access (NBMA) networks, such as wide area technologies including ATM, frame relay, and X.25, the network interface address is not the MAC address. Instead, it is a virtual circuit.” ... “Inverse ARP (InARP) is used to resolve the IP address on the other end of the virtual circuit. InARP was specifically designed for frame relay circuits.” Similar text can be found on the first couple of paragraphs of Davis J., Lee T. Win Svr 2003 TCP/IP book, pages 29-30.

If InARP was really a part of the standard ARP protocol, then this would seem like a process that would be easy to implement, and so popular operating systems would have this protocol supported. A popular method is to try to get the system to respond to an ARP request, and then check the system's ARP cache. (A similar thing may be done by checking for IPv6 NDP neighbor data. In Microsoft Windows, try “ netsh interface ipv6 show neighbors level=verbose ”. In OpenBSD, try “ ndp -a ”. In Linux, try “ ip -6 neighbor ” unless your native tongue is one that prefers to type “ ip -6 neighbour ”, as that may also work as well.)

If the information is not found in the ARP cache for IPv4 or the NDP neighbor cache for IPv6, perhaps the desired information can be added to the desired cache. Superuser site: Question about implmenting inverse ARP has a recommendation saying “The easiest way to do this is to ping the broadcast address”. (In Linux, pinging the local subnet's broadcast address may be disabled unless -b is specified.) However, SuperUser answer 29693 notes that pinging a broadcast address may not work when “broadcast pings are discarded (a very common situation)”. When that doesn't work, then some people will try techniques like trying to ping every address in a subnet. (That may be more feasible with small subnets.)

Making a program to help automate this process (of pinging a whole subnet) is probably fairly simple. Here are some references to some untested, unverified programs. (Always perform any wise cautions about determining what is safe before running any untrusted code!) As also noted on Superuser site: Question about implmenting inverse ARP, arping may come with a file named (that may be helpful in Unix). forum posting about getting Inverse ARP info provides quuxo's VBScript, and a batch file equivilent. Another implementation may be at: VBScript implementation

Commentary about trying to use software built into Windows. Commentary indicates that there is no widespread support for this. (Even if some software sent the request, a common computer may not have support to respond to the request.)


Used with IPv6.

For some details, see:

Documentation MAC-48 addresses

For MAC-48 addresses, IETF BCP 141: IANA/IETF/Doc Usage related to IEEE 802 (and, more specifically, IETF RFC 7042 section 2.1.1: MAC addresses reserved for IANA and, an even more focused section, IETF RFC 7042 section 2.1.2: MAC addresses reserved by IANA for documentation) notes the 01-00-5E- MAC address range 01-00-5E-00-53-00 through 01-00-5E-00-53-FF for Unicast examples, and 01-00-5E-90-10-00 through 01-00-5E-90-10-FF as multicast addresses reserved for documentation.

This was found by checking out: IANA: Ethernet numbers, which does refer to (or has referred to) RFC 7042.

Also, 00-00-5E-00-42-?? may be a range of documentation addresses, as noted by RFC 7042 section 3.2? Although, this did appear to be more related to the “protocol” field.

[#euisixfr]: EUI-64
Standard EUI-64

IEEE Tutorial: Use of Extended Unique Identifier (“EUI”) and similar, archived in July 2010 by the Wayback Machine @ defines EUI-64, stating that it “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.” (Hyperlink added to quoted text.)

Wikipedia's article on “MAC Address”: section called “Address details” states, “EUI-64s are not expected to run out in the foreseeable future.” (This statement was made right after a statement that indicates MAC-48 is anticipated to last until the year 2100.)

[#modeui64]: “Modified EUI-64”

The “Modified EUI” format described by RFC 4291: “IPv6 Addressing Architecture” section 2.5.1: “Interface Identifiers” (especially after the start of page 8) simply reverses the meaning of the seventh bit (the universal/locally administered bit) of the address. By making this one change from the interpretation specified by IEEE's standard for an OUI, locally administered OUI's will have a zero. The end result allows many privately-assigned addresses to be better condensed by IPv6's double-colon.

A (recommended) method for creating these types of addresses is also available later in that same RFC. See: RFC 4291: “IPv6 Addressing Architecture”, Page 20, the start of Appendix A: “Creating Modified EUI-64 Format Interface Identifiers”

Documentation EUI-64 addresses

Since MAC-48 addresses may be embedded in EUI-64 addresses, this naturally means that the information about MAC-48 addresses could be used to find some EUI-64 addreses that may be used. However, there is some additional documentation specific to EUI-64. IETF BCP 141: IANA/IETF/Doc Usage related to IEEE 802 (and, more specifically, IETF RFC 7042 section 2.2.3: EUI-64 addresses may provide such details.

For more details (such as details about the OUI), see the broader topic EUI addresses, which includes details relevant to this topic of EUI-64.


IEEE Tutorial: Use of Extended Unique Identifier (“EUI”) and similar, archived in July 2010 by the Wayback Machine @ mentions EUI-64 and some other identifiers, including EUI-60 which the document describes: “The use of the EUI-60 identifier is deprecated. Since the EUI-60 identifiers form a portion of World Wide Names (WWNs) value defined within multiple disk related standards, there is no plan to eliminate the use of these EUI-60 values within the forseeable future. The term deprecated does not imply a demise of EUI-60 identifiers, but implies the EUI-64 (as opposed to EUI-60) identifiers should be used in future applications requiring the use of unique per-hardware instance identifiers.” (The quoted text had some errors with spacing which has been corrected when being quoted here.)

Wikipedia's article on “Ethernet frame” (last update from February 2013), “Note 5” states, “A version 1 Ethernet frame was used for early Ethernet prototypes and featured 8-bit MAC addresses and was never commercially deployed.”