Hacker News Reader

Comment by throw0101b | Hacker News Reader

Somewhat related:

The choice of 48 bits for the hardware/station address seems to have been a pretty good choice: it's been 40+ years and we still have no run out. I'm curious to know if anyone has done the math on when Ethernet address exhaustion will occur.

While the Ethernet frame has been tweaked with over the decades, addressing has been steady. Curious to know if any transition will ever been needed and how would that work.

In hindsight, IP's (initial) 32 bit address was too small, though for a network that was (primarily) created for research purposes, but ended up escaping 'into the wild' and accidentally becoming production, it was probably a reasonable choice: who expected >4 billion hosts on an academic/research-only network?

View on HN

We're unlikely to ever actually run out. Ethernet addresses are expected to be universally unique, but they're only required to be unique within a collision domain. If someone started reusing addresses from 3c503s, chances are high nobody would notice. If we did run out, devices would need to start generating randomized addresses, and maybe probe for collisions, which isn't unworkable; the number of nodes in a collision domain tends to be low, and the space is large, you might only barely need to to probe for collisions at all if you have a good random source.

Some quick napkin math on the current MAC vendors database: 46 bits of a MAC address are reserved for universally administered unicast (i.e. a globally unique MAC assigned to identify a device). So far we have assigned ~570 billion addresses via 24/28/36 bit range assignments for the same purpose which represents a little under 1% of the space. So nothing urgent, though if we stuck with Ethernet as much as we use it today then in <100 years I wouldn't be surprised if we were "out".

At the same time there are also 46 bits of locally administered unicast addresses and, unlike IP, Ethernet addresses only care about the local network (and this isn't a "because we've co-opted them to to save space just like NAT broke IP protocols" rather the design intent of Ethernet). Even if you had 10 billion LANs with 100 devices each and they all used this random non-unique assignment there would only be a ~50% chance there one or more devices would have a collision.

The only real advantage I've ever been able to find of programming in unique MAC addresses vs random MAC addresses you can look up what company the MAC was assigned to. It may seem like there is a risk random assignment can be done poorly (e.g. not very randomly) but honestly the same risk exist with assigned ranges as seen by network vendors cheaping out and re-using their MAC blocks (which is significantly more likely to conflict than if they just used random locally administered addresses in the first place).

So when XSIS (Xerox System Integration Standards?) first started selling MAC address blocks in the early 1980s, I think it cost $1k for 16M mac addresses (168 addresses per penny). So there are only 16M blocks of mac addreses available, and it IS possible to run out, if vendors waste the addresses. I don't know what registration costs from The IEEE right now, but once the equivalent of $16B is spent on mac addresses, we will run out of blocks.

Maybe today they are selling smaller blocks but the MAC is basically divided into 16M blocks (specified by the first 24 bits / 3 bytes) - each with a registered owner or "unassigned") and 16M MACs within the block (the lower 24 bits). That's why you can enter a MAC address into a lookup website and find out who made the NIC (google search "mac address lookup"):

https://aruljohn.com/mac.pl

It was Xerox & Yogen Dalal's choice, not Bob's choice! Xerox blew it with 8-bit station addresses in PuP (PARC Universal Protocol) and wanted to give each station a UID to break ties in database transactions, hence the 48-bits. XNS actually had 3-byte station and 3-byte network size to fit in 6-byte MAC addresses! Metcalfe is not a software engineer and wouldn't have these insights ...

Reply on news.ycombinator.com