Why do we need MAC addresses?
immibis.com
immibis.com
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.)
(Also, to have been a fly on the while when you worked out that whole congestion thing.)
When it became clear that packet switching was going to win out, did the telcos ever try to emulate circuits with UDP flows or similar? It seems like IP over switched circuits would look a lot like virtual switched circuits over IP, if you squint just right.
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.
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.
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.
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...
I would never do such a thing now of course.
The idea of a two-port switch sounds silly until you realize there can be 30 devices on each port.
The main purpose of bridges like that was to overcome the electrical limitations of coax Ethernet. Cable losses, transceiver losses, and length limitations meant that beyond some length, you needed a power booster.
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.
Good to see adoption is happening, even if it’s slow.
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.
The headers of IP packets wouldn’t be affected by MAC addresses, Ethernet packets carry IP packets as their payload and would have their own headers as appropriate.
A router’s job is essentially to “pass on” or relay IP packets based on its routing tables, they are what connect networks together.
> A typical packet found on a typical network has a structure like this:
> Destination MAC address
> Source MAC address
You can put other things than IP packets inside Ethernet frames. You can put IP packets into non-Ethernet carriers.
The short version is that small LANs route frames by MAC addresses and don’t know about IP addresses, and the Internet cares only about IP addresses and not MAC addresses.
Notably, none of this implies IP. IP was the expensive DARPA project that the military was building out. Ethernet is just "I am machine X, I want to talk to machine Y, here's some data". It just so happens that Ethernet was very popular, and people wanted to route IP over Ethernet. But you could route all sorts of other protocols over Ethernet as well and it would more or less work. So now we need two different classes of addressing: one for just the local network, and one for the IP network running on top of it.
And to make matters even worse, we don't use Ethernet in its original configuration anymore. First we replaced the loop of coax and vampire taps with 8P8C wire and passive hubs, then switches got cheap enough that we stopped making hubs. Ethernet framing also wound up being used for Wi-Fi, except like 99% of all Wi-Fi connections are in Infrastructure mode running IP anyway.
If Ethernet had been built to run IP exclusively, we wouldn't need Ethernet's header or MAC addresses at all. It would just need to encode IP packets and their boundaries. Even IPv6 wouldn't need a separate header as IP has its own version field.
[0] MAC addresses are supposed to be unique, but let's just say it's "LAN-scoped" and leave it at that.
The article refers to a "typical packet found on a typical network" then describes an Ethernet frame, so the author clearly refers to MACs in an Ethernet setup.
MAC is part of the Ethernet standard. The clue of why is needed for is in the name "access control". Without MAC there's no Ethernet. Without Ethernet there's no Internet.
Wait ...there are other networking standards!
You _could_ design a system where MAC addresses were always randomized, but this technology evolved at a time where processing power and the bandwidth of your switches likely might have struggled with the additional load.
If we were designing a system from scratch it would probably make sense for everything to have hierarchical, switch-local identities that were cheap to allocate and check and put a bit more extra routing storage in the switch chips to efficiently route these.
Until you consider broadcast/multicast traffic.
Every NIC on the wire saw every packet; the destination mac address indicated whether the packet was interesting enough to each node to be worth putting a copy in host memory and bothering the CPU to look at.
They commonly had “collision” lights, and they used ‘em.
This is fundamentally incorrect. IPv4 for LAN, sure - but "bootstrap" it is not.
There's plenty of L2 that have no MAC: PPP, ATM, Frame Relay, etc. Also, MACs aren't needed for IPv6. ND works without MAC in v6.
And, finally... There's no MAC for loopbacks.