Juha Saarinen dropped me a note a week or two back, asking for an update to my last post, in the wake of the IANA IP address pool finally running out and the recently announced successful bid for Nortel Networks’ IP address space by Microsoft for inclusion in NZCS Newsline.
The published article can be found here, and is different enough from the previous version to warrant re-posting.
I hate IPv4 link broadcast interface (e.g. Ethernet) addressing semantics. To recap, if I have two boxes on each end of a point-to-point link (say between a gateway and an end host), we address as follows (for example):
That’s four IP addresses, for a link to a single host. Hello? Haven’t you heard the news? IP addresses are running out!
Some folks manage to get away with using /31 masks, e.g.
which is just wrong. Better in terms of address usage (two addresses instead of four), but still just plain wrong. An you’re still wasting addresses.
The PPP folks a long time ago figured that a session, particularly in client to concentrator type configurations, only needs one IP address. A “point to point” interface has a local address, and a remote address, of which only the remote address needs to be stuffed in the routing table. The local address can be the address of the concentrator, and doesn’t even need to be in the same subnet.
So why can’t my Ethernet interfaces work the same way?
A point to point link really doesn’t have broadcast semantics. Apart from stuff like DHCP, you never really need to broadcast — after all, our PPP friends don’t see a need for a “broadcast” address.
Well, we decided we had to do something about this. The weapon of choice is NetGraph on FreeBSD. NetGraph basically provides a bunch of kernel modules that can be linked together. It’s been described as “network Lego”. I like it because it’s easy to slip new kernel modules into the network stack in a surprising number of places. This isn’t a NetGraph post, so I won’t spend more verbiage on it,but it’s way cool. Google it.
In a real point-to-point interface, both ends of the link know the semantics of the link. For Ethernet point-to-point addressing, we can still do this (and my code happily supports this configuration), but obviously both ends have to agree to do so. “Normal” clients won’t know what we’re up to, so we have to do this in such a way that we don’t upset their assumptions.
So we cheat. And we lie. And worst of all,we do proxy ARP!
What we do is tell our clients that they are on a /24 network. Their IP address is, for example, 10.1.2.5/24, and the gateway is 10.1.2.1. Any time we get a packet for 10.1.2.5, we’ll send it out that interface, doing ARP as normal to resolve the remote host’s MAC address.
Going the other way, we answer ARP requests for any IP address in 10.1.2.0/24, except 10.1.2.5, with our own MAC address. That means that if they ARP for 10.1.2.6, we’ll answer the ARP request, which directs that packet to us, where we can use our interior routes to route it correctly. In our world, two “adjacent” IP addresses could be on opposite sides of the network, or it could be on a different VLAN on the same interface.
The result is one IP address per customer. We “waste” three addresses per 256, the network (.0), gateway (.1) and broadcast (.255), and we have to be a bit careful about what we do with the .1 address — it could appear on every router that is playing with that /24. But we can give a user a single IP address, and put it anywhere in the network.
We can actually have multiple IP addresses on the same interface; we do this by having the NetGraph module have a single Ethernet interface but multiple virtual point-to-point interfaces. So if we want to give someone two IP addresses, we can do that as two, not necessarily adjacent, /32 addresses. We don’t answer ARPs for any of the assigned addresses, but do answer everything else. The module maintains a mapping of point-to-point interface to associated MAC address.