The MAC address is meaningful only for a single link. It doesn't get copied through routers and get carried along to the destination. (At least in theory. Between software defined network hardware and enterprise WiFi, there are cases where MAC addresses have wider scope. But they rarely leave an organization.)
The Xerox plan for Ethernet was to use XNS, with a 32-bit network ID and a 48-bit MAC. Routers only had to know how to find a network ID, and once the packet hit the correct destination network, the MAC address routed it to the destination.
Early on, there was a thing for "multi-protocol routers", that forwarded XNS, DECnet, IP, and a few other things such as Parc Universal Protocol, PUP. Cisco was once big on this, because Cisco came out of Stanford, which had a few of everything and tried to interconnect them.
In the 1990s, most of those branded protocols died out, although as late as Windows 2000, Microsoft still supported TP4, a bad idea from circuit-oriented telco people. There was a telco approach to networking, where you dialed up a reliable circuit to your destination, transmitted what you had to send, and later got a bill for the call. This, fortunately, lost out to IP.
(I had real doubts about pure datagram long distance networks. We didn't know how to deal with congestion in the middle of a pure datagram network. We still don't, but cheap fiber saved us from having to.)
> The MAC address is meaningful only for a single link
This isn't entirely true. In ye-olden days, Ethernet was a proper bus architecture, where you would have many devices talking on a single line.
As networks got larger, we wanted to have more devices than we could get on a single cable, so we introduced cheap booster hubs that would physically connect multiple cables. Since these hubs didn't have any fancy switching logic, it continued to look to devices like everyone was on a single bus (which they basically were).
Eventually, compute became cheaper, and the limitations of having a massive bus more apparent, so we started replacing some of the Ethernet hubs with Ethernet switches to reduce contention. It still looks as if everyone is on a single bus; but now a node only sees traffic involving a node on its side of the nearest switch. Notably, these switches were drop in replacements for hubs, so they did not rewrite MAC addresses.
Nowadays, actual Ethernet hubs are a dying breed (although I still keep one lying around to avoid buying an expensive managed switch with a monitor port). Almost every Ethernet cable you run into today is a genuine point-to-point connection connecting two specific nodes, and carrying only the data that needs to be sent between those nodes.
Now that modern Ethernet is a full featured packet switched protocol, it has to deal with all the routing issues that come with that. This led to the introduction of the Spanning Tree Protocol, to allow Ethernet switches to construct Ethernet routing tables. Notably, nothing inside of these Ethernet networks replaces MAC addresses. When computer A sends to computer B on the same Ethernet network, the destination MAC address A uses is B's actual MAC address, regardless of how many switches are between them.
The really awesome part about Ethernet hubs was that if you knew what you were doing, you could get everything on the bus delivered to your device. Fun fact, in the 90s, most every college dorm had one hub per building (or if you were at MIT, one huge network for all of them).
Since most everything ran over plain text, you'd be surprised what you could learn when you aggregated all AOL IMs and ICQ messages in one interface...
Someone recently did a YouTube demonstration of an Ethernet bridge: https://www.youtube.com/watch?v=Hvqv9QcTcfA (skip to 15:22). It's a large, $8000 (in 1986), 10kg device with a 68000 processor that connects to exactly two ethernet busses via AUI ports. It even speaks an earlier variant of STP. It remembers a certain number of MAC addresses on each bus, and when it sees a packet on one bus addressed to a device on the other bus, or a broadcast, it stores it and sends it when the other bus is free.
The idea of a two-port switch sounds silly until you realize there can be 30 devices on each port.
>so we started replacing some of the Ethernet hubs with Ethernet switches to reduce contention.
I just remembered having to answer questions about Ethernet hubs vs switches many years ago. To me, ethernet hubs are entirely theoretical, I don't think I've ever seen one in the wild.
Don’t get me started on the ugly detour that was ATM, for when Bellheads wanted to build out the Internet like a phone switch, and when no one could agree on optimal cell sizes and they compromised on 53 bytes to piss off everyone equally.
(Also, to have been a fly on the while when you worked out that whole congestion thing.)
It took over two decades for things to settle. The telco people had ATM and Frame Relay and DSL voice and a Bell Labs thing called Datakit. They were trying to get deterministic voice, so voice over packets wouldn't suck. What we ended up with is voice with lag, jitter, echo, dropout, and over-compression. So nobody talks on the phone much now.
I remember working on a federal contract back in the early 2000s where there was a camp of ATM folks against us who were pushing Metro Ethernet and MPLS. The TL;DR of it was the ATM guys won, spent millions of dollars, only for us to come in and replace it all a year after it was supposed to have been done in the first place.
Cisco sure made some good money on failed ATM projects back then!
Something seems a bit off about this article. "Because Ethernet came first" is the real answer; and it being a local network technology, was not readily scaled beyond that, despite the MAC address space being 64k times larger than the IPv4 address space. A key point worth noting about the IP address space, which enabled this crucial scaling to global networks, is its hierarchical structure. MAC addresses are assigned to hardware interfaces, independent of their location, while IP addresses are assigned hierarchically much like numbers in the telephone system, allowing for relatively easy routing at a global scale.
A typical packet found on a typical network has a structure like this
IPv6? That's... not really "typical", yet. IMHO even packets with 802.1q tags are going to be more commonly found and "typical" than IPv6.
I see the Ethernet coming first answer in another comment too. Just to be clear, many protocols came before IPv4 that aren't in play. It's not because it came first, it's because they're layered. Why need an IP if you have a port number? Why need a port number if you have a url?. As also mentioned in a comment, there's IPv4 over not just Ethernet. So I agree with your comment, but a bit of pedantry goes a long way
> Why don't we just make IP networks without Ethernet?
The article implies that we need MACs, and of course we don't, and lots of protocols exist that don't use ethernet framing. SLIP and PPP only speak IPv4, for example.
Also the real reason behind the "why" is more boring than the blog implies. Ethernet predates IP. It's a simple (almost the simplest possible) protocol for a bunch of hosts to share a single network without running into trouble talking to each other. And it decided on a hardware-unique "MAC" as its way of doing addressing.
It was simple, so it was cheap. So everyone built out cheap ethernet hardware. And when it arrived, everyone wanted to run IP on their cheap ethernets.
IP and routing is actually the interesting question. Somehow we need to get these IP packets to right place. And this opens up question how would it be done with just IP packets? You would at least need some extra protocol over IP as IP itself really does not have idea where the next jump on the route is...
Routing on Internet scale is messy question really. And then moving physical bits over any medium is also somewhat complicated always. So ethernet and MACs works relatively well for helping in both...
Still, it is somewhat nice thought exercise to think how you would do without it.
Media Access Control (MAC) address is the method to control access to the physical transmission medium. A switch doesn't care about your upper layers (IP, TCP, etc.) but won't find your host without a MAC address. That's why MACs are called hardware address and work on the local link only, from the port on your cool network interface to the other end of the cable or radio signal.
At university, our network required antivirus to be installed, which really sucked and destroyed the performance of your machine. So my laptop became an Xbox, which was exempt from antivirus policies :)
We don't NEED it, just like we don't need to use IP. But the standards are just easy to use. Feel free to develop your own L2 protocol. I remember using SLIP to make a point to point over FM radio, and there was no addressing used, just IP.
Article is pretty spot on. We need MAC addresses for local area networking. Nothing is stopping you from using any physical layer outside of your home network. But of course everything client these days uses Ethernet based technology.
Readit News
The Xerox plan for Ethernet was to use XNS, with a 32-bit network ID and a 48-bit MAC. Routers only had to know how to find a network ID, and once the packet hit the correct destination network, the MAC address routed it to the destination.
Early on, there was a thing for "multi-protocol routers", that forwarded XNS, DECnet, IP, and a few other things such as Parc Universal Protocol, PUP. Cisco was once big on this, because Cisco came out of Stanford, which had a few of everything and tried to interconnect them. In the 1990s, most of those branded protocols died out, although as late as Windows 2000, Microsoft still supported TP4, a bad idea from circuit-oriented telco people. There was a telco approach to networking, where you dialed up a reliable circuit to your destination, transmitted what you had to send, and later got a bill for the call. This, fortunately, lost out to IP.
(I had real doubts about pure datagram long distance networks. We didn't know how to deal with congestion in the middle of a pure datagram network. We still don't, but cheap fiber saved us from having to.)
This isn't entirely true. In ye-olden days, Ethernet was a proper bus architecture, where you would have many devices talking on a single line.
As networks got larger, we wanted to have more devices than we could get on a single cable, so we introduced cheap booster hubs that would physically connect multiple cables. Since these hubs didn't have any fancy switching logic, it continued to look to devices like everyone was on a single bus (which they basically were).
Eventually, compute became cheaper, and the limitations of having a massive bus more apparent, so we started replacing some of the Ethernet hubs with Ethernet switches to reduce contention. It still looks as if everyone is on a single bus; but now a node only sees traffic involving a node on its side of the nearest switch. Notably, these switches were drop in replacements for hubs, so they did not rewrite MAC addresses.
Nowadays, actual Ethernet hubs are a dying breed (although I still keep one lying around to avoid buying an expensive managed switch with a monitor port). Almost every Ethernet cable you run into today is a genuine point-to-point connection connecting two specific nodes, and carrying only the data that needs to be sent between those nodes.
Now that modern Ethernet is a full featured packet switched protocol, it has to deal with all the routing issues that come with that. This led to the introduction of the Spanning Tree Protocol, to allow Ethernet switches to construct Ethernet routing tables. Notably, nothing inside of these Ethernet networks replaces MAC addresses. When computer A sends to computer B on the same Ethernet network, the destination MAC address A uses is B's actual MAC address, regardless of how many switches are between them.
Since most everything ran over plain text, you'd be surprised what you could learn when you aggregated all AOL IMs and ICQ messages in one interface...
The idea of a two-port switch sounds silly until you realize there can be 30 devices on each port.
I just remembered having to answer questions about Ethernet hubs vs switches many years ago. To me, ethernet hubs are entirely theoretical, I don't think I've ever seen one in the wild.
(Also, to have been a fly on the while when you worked out that whole congestion thing.)
Cisco sure made some good money on failed ATM projects back then!
If every packet is the same size your packet processing can be much faster.
A typical packet found on a typical network has a structure like this
IPv6? That's... not really "typical", yet. IMHO even packets with 802.1q tags are going to be more commonly found and "typical" than IPv6.
Ethernet can't scale like IP because it's a non-hierarchical address structure.
> Why don't we just make IP networks without Ethernet?
The article implies that we need MACs, and of course we don't, and lots of protocols exist that don't use ethernet framing. SLIP and PPP only speak IPv4, for example.
Also the real reason behind the "why" is more boring than the blog implies. Ethernet predates IP. It's a simple (almost the simplest possible) protocol for a bunch of hosts to share a single network without running into trouble talking to each other. And it decided on a hardware-unique "MAC" as its way of doing addressing.
It was simple, so it was cheap. So everyone built out cheap ethernet hardware. And when it arrived, everyone wanted to run IP on their cheap ethernets.
Routing on Internet scale is messy question really. And then moving physical bits over any medium is also somewhat complicated always. So ethernet and MACs works relatively well for helping in both...
Still, it is somewhat nice thought exercise to think how you would do without it.
So we can spoof them, of course.
They seem to get more abuse over time i.e. MACs are how a car is uniquely identified and authenticated with fast charging CCS networks for Autocharge.
They kinda are already, your phone probably uses a random MAC address for each network it connects to.