Back to Basics: Do We Need Interface Addresses?
In the world of ubiquitous Ethernet and IP, it’s common to think that one needs addresses in packet headers in every layer of the protocol stack. We have MAC addresses, IP addresses, and TCP/UDP port numbers… and low-level addresses are assigned to individual interfaces, not nodes.
Turns out that’s just one option… and not exactly the best one in many scenarios. You could have interfaces with no addresses, and you could have addresses associated with nodes, not interfaces.
Unnumbered Interfaces
Imagine you’re in a crowded ballroom and you want to do a random chat with Alice, Bob, or Charlie. It makes perfect sense to prepend your sentence with “Bob, what do you think about…” if you want to chat with Bob, right? Likewise, you need link-layer addresses on multi-access links (shared Ethernet, WiFi), and you need network addresses in networks having more than two nodes.
What about sitting in a quiet room with Bob seated across the table from you? Does it make sense to preface everything you’re saying with “Hey, Bob!” Obviously not.
Similarly, you don’t need link-layer addresses on point-to-point links, and yet we almost always use them for historical reasons:
- SDLC, the grandfather of most serial-line protocols (including HDLC and PPP), supported multidrop – the ability to connect more than two nodes to a single modem link – and thus needed link-layer addresses.
Multidrop is still used on cable and PON networks
- All derivations of SDLC retained them because it was easier to reuse the existing hardware devices than to persuade the hardware manufacturers to do something else.
Every PPP frame includes an unnecessary broadcast destination address
- Ethernet was designed to be a multi-access network. Also, Ethernet switching pretends that point-to-point segments between the end nodes and switches belong to a giant virtual multi-access cable, and thus you cannot get rid of MAC addresses. However, when we started using Ethernet for router-to-router links1, we could reduce the size of the Ethernet header. Still, it was more convenient to reuse existing hardware than to work hard to save the 14 bytes of every frame.
A few protocols got it right, though:
- SLIP was designed to carry IP packets over dial-up links. Adding another layer of addresses was unnecessary, and as they started from scratch and used existing character-mode hardware, they could get away with it.
- PPPoE dropped the HDLC addresses used in PPP frames and started the PPP payload with protocol ID.
- Fibre Channel (FC) designers realized you don’t need layer-2 and layer-3 addresses in a single-protocol network and decided to use layer-3 addresses everywhere. That decision confused some FC practitioners to the point where they claimed FC is switching, not routing (whatever the difference is), even though the standard documents are unambiguous.
Interface and Node Addresses
Now you know why you need link-layer addresses on multi-access links, but do we need network-layer addresses on each interface?
Coming back to the ballroom example: Bob has two ears, but when you want to chat with Bob, you start with “Hey, Bob…” not with “Hey, Bob’s left ear…”, or as @odecentralize put it:
Assigning IP addresses to interfaces is like having people address you by a different name depending on which door they used entering the building.
To reach a node, you need a unique network address per node, not per node’s interface, and yet the IP designers went the other way. We’ll explore their reasoning in the second part of this series.
An IP node has to use a different IP address on every interface
A CLNS node has a single address, regardless of how many interfaces it has
It’s worth noting that the “address-per-node” paradigm is not gone even in the world of IP/Ethernet. You’ll find it in Ethernet bridging (bridges have a single node-wide MAC address), and we commonly use loopback IP interfaces when we want to make an IP address of a multi-interface IP device (often known as a router) stable.
More to Explore
If you find this blog post interesting (or you wouldn’t get this far), you might like the Network Addressing part of How Networks Really Work webinar.
Revision History
- 2021-05-05
- Added a tweet by @odecentralize
-
Or switch-to-switch links if you’re of marketing persuasion. ↩︎
Enjoyed, thank you Ivan.
Yes, I think you need interface addresses (on network-layer) for troubleshooting and monitoring purposes. Or you want to use something along OAM?
@Anonymous: and we're back to the discussion we had more than five years ago:
https://blog.ipspace.net/2016/01/are-unnumbered-interfaces-harmful.html
I wonder why we can't ever agree on something and move on.
Until now I never came into a situation where there was full agreement from people on a subject. Good example is that recent horrific pandemic. But I agree with you on this: "Speaking of traceroute: it might give you wrong interface information any time you happen to have asymmetrical routing or multiple equal-cost paths." Don't get me wrong, I've nothing against unnumbered interfaces. For me they make sense in particular environments. But why shouldn't there be no drawbacks with unnumbered interfaces?
@Anonymous:
> But why shouldn't there be no drawbacks with unnumbered interfaces?
I'm not saying there are no drawbacks. Everything has drawbacks... or you haven't looked hard enough. It's just that I keep getting the same "monitoring and troubleshooting" arguments, even though they weren't exactly valid for years if not decades.
Although having IP per interface still makes a lot of sense, so we have a control over how the traffic reaches the node, especially if have different speed/latency links and want to use some specific one (BGP over unnumbered interfaces is a wonder, but adds some complexity that this is not always welcome).