A MAC address is needed to bootstrap IP, even if non-routable - and because we don't want to bootstrap MAC addresses, we just assign them statically. From the very beginning (oversimplifying a bit, but I digress), a MAC has really just been the key in a hashed map from MAC to switch port.
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.
In the very beginning of ethernet there were no switches - you just had a bunch of transceivers connected to a length of coax cable.
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.
a bit disappointed this only points to ethernet as its answer. it does help to understand why ethernet requires addressing versus some others that do not.
> 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.
When a router is used you still do see the MAC address but only of the directly connected next hop/device. If another router, then it would change the headers appropriately.
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.)
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.
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.
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.
"The Internet doesn't use MAC addresses, and Internet packets don't have MAC addresses" is a wrong assumption. What's an "Internet packet"? Without MACs there's no networking. Without networking there's no Internet.
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.
17 comments
[ 2.9 ms ] story [ 39.4 ms ] threadYou _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.
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.
> A typical packet found on a typical network has a structure like this:
> Destination MAC address
> Source MAC address
> 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.
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.)
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.
So we can spoof them, of course.
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.
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.