rand()?

A MAC address is 48 bits and an IMEI is about the same entropy-wise. That's not nearly enough room to avoid duplicates (even SLAAC requires duplicate address detection, and IPv6 has a lot more bits to work with). You'd need a whole new layer 2 protocol, though to be fair you might be able to strip it down to just doing collision detection/avoidance and leave addressing up to layer 3 with IPv6, but that's not going to be any kind of backwards compatible or interoperable.

Surely the uniqueness is only required at the bottom end of the stack before the first 'router' ie the cell tower

> Surely the uniqueness is only required at the bottom end of the stack before the first 'router' ie the cell tower

Not if you need to send a message to $thatUniquePhone.

Over simplifying considerably, but if a land line places a call to a mobile, the "220-1234 calling for 220-7890" message enters the network. The `220-7890` phone number needs to map to the unique modem address so you can look up which tower the call setup data should be sent to. If - by sheer coincidence - I also have your MAC address and am attached to a tower 3 states away... which tower(s) do you forward the call setup data to?!

> which tower(s) do you forward the call setup data

Whichever one has most recently communicated with the user in question (based on the credentials or certificate provided, in the original example)

Assuming something like VoIP is in use, you reach other devices with their IP addresses, not MAC addresses.

As far as I know MAC addresses are never used to route a message to a particular recipient. They're used so that devices that overhear the message, but aren't the intended recipient, can ignore that message on the honor system.

If you have a wired connection, this makes the MAC completely superfluous. The concept is sort of still valid for wireless connections (or of course for "wired" connections where you have multiple devices physically connected by the same wire, a bus, where the concept originated). It should be rethought.

Yes - the whole MAC/ARP/IP parts of the typical IP stack are a legacy mess and should be sorted out.

A typical Ethernet switch operates only at layer 2 and so does indeed route frames by MAC. You need a more expensive, typically managed, switch in order for it to use layer 3 addresses instead and, even then, the initial setup usually relies on layer 2 routing to get an IP address before layer 3 routing can take over. As a sibling comment points out, the whole stack would/does need a rethink to work differently than this. IPv6 SLAAC as mentioned before can potentially eliminate the need for layer 2 addresses but a lot of networks are still IPv4-only, dual-stack, or even layer 3-agnostic.

Note that this is only about last-mile/first-hop. Once you scale past a single LAN segment, routing is mostly layer 3 until you get to core Internet infrastructure which uses ASNs and BGP. At the very least, it is probably sufficient to say that routing across a WAN is all about IP, but if you zoom in on parts of that network of networks, the underlying technologies often use other routing mechanisms internally that don't get exposed to the other parts of the WAN.

Yes, but you could have hundreds of thousands of devices connected to that tower in a dense metro area. Even a single hardware address collision would result in both devices being unable to reliably reach emergency services.

It seems a number of devices are now randomizing their MACs when connected to wifi. I'm not sure how they handle address collisions, if they do at all. Most wifi APs serve a lot fewer devices than a cell tower, but it's possible that the issue isn't as significant as I thought.

The use of IPv6 in cellular devices is specified by RFC 7066. When a device first registers for a data connection, the network provides an interface identifier to use for the lifetime of the registration, which is guaranteed not to conflict with the one used by the router. The network also allocates a /64 prefix exclusively for use by the device. These two things allows the device to perform SLAAC for link-local and routable addresses without needing to do duplicate address detection.

It’s also worth mentioning SLAAC does not strictly require a hardware address to function. For example, Apple devices implement newer standards from IETF to generate random but stable addresses that don’t reveal information about the hardware addresses (https://support.apple.com/guide/security/ipv6-security-seccb...)