We have just built our small kingdom.
One valley, a few villages, a few signal towers, and a local network that works surprisingly well for something invented by people who still believe that medicine is mostly a matter of balancing four bodily fluids.
Unfortunately, sooner or later power becomes the main goal of the most ambitious people in the kingdom, and sooner or later one kingdom becomes too small for them.
Scouts discover settlements behind the mountains, armies march along roads that were previously used for sheep, and within a few years our neat little kingdom becomes an empire with several valleys somewhere beyond the horizon.
The moral dilemma is outside the scope of this article, and we, as network engineers in medieval Europe, are definitely not in a position to judge the military policy of our lords.
What we do need to judge is whether the communication system from Part 1 can survive this expansion.
It cannot.
Our old system knows how to move a frame inside one valley, but it has no idea what a valley is, where its border lies, or what to do when a destination is hidden behind three mountain passes and somebody else's tax system.
So we will build the larger system in the same way we built the local one.
We will remain with our towers until messages can cross the whole empire, and only after the machinery works will we return to a real computer and the Internet.
This order matters because IP addresses, gateways and routing tables are much easier to remember when they arrive as answers to problems we have already felt.
In this post we will discuss how IP addresses, network prefixes, gateways, routing tables and ARP turn local networks into a network of networks.
We will then see how the same model appears on Linux, how DHCP gives a host the information it needs, and what changes while one packet crosses several routers.
The real-world part focuses on IPv4 carried over Ethernet.
Other link technologies can carry IP without Ethernet, and IPv6 uses Neighbor Discovery instead of ARP, but one carefully bounded world is enough for now.
Our empire is already difficult to govern without opening several additional continents.
Two orders of names In our existing system every tower already has a local name such as , or , and that worked perfectly while the entire known world fitted inside one valley.
Then we acquired another valley.
It has its own towers, which may be called , and .
They may also be called , and , because coordination between medieval kingdoms is apparently not much better than coordination between modern IT departments.
Now an order addressed to is ambiguous.
There is an in Valley 1 and another in Valley 2, and the old name tells us who should receive a message only after we already know which local network we are talking about.
This is not a flaw in the old system.
A local name was invented for local delivery, and inside one valley it still does that job perfectly.
The empire has simply created a second question that the local name was never meant to answer: In which valley does the destination live?
So we introduce another order of names.
Tower keeps its local address and independently receives the wider address .
A tower in Valley 2 may reuse the same local address while independently receiving .
The local and wider addresses are not constructed from one another.
They are separate identifiers assigned for different scopes.
Figure
1.
The local address can be reused in both valleys.
The independent wider addresses and identify the towers across the empire, and neither is derived from .
We have just reconstructed the reason a machine can need both a MAC address and an IP address.
The MAC address is the local name.
It identifies the immediate sender or receiver on one Ethernet network.
The IP address is the wider name.
It identifies the source and destination across many connected networks.
The two addresses do not compete, and one is not a more modern replacement for the other.
They describe the same machine at different scopes, rather like a person's room number and full postal address.
A room number can be perfectly useful inside one building even though a letter crossing the country needs more information.
Is the destination still inside our valley?
Imagine that tower in Valley 1 receives an order: Deliver this message to .
The destination begins with , and our tower also belongs to , so the destination is local.
It can use exactly the machinery we built in Part
1.
It discovers which local tower owns , learns that tower's local address if necessary, and sends a frame through the valley.
Then another order arrives: Deliver this message to .
This time the wider address tells us something important before a single signal is sent.
The destination belongs to Valley 2, while our tower belongs to Valley
1.
None of the local towers can deliver a frame directly through the mountain.
Our medieval rule can still be very simple: Modern networking calls the precise version of this boundary a network prefix, but we do not need the binary notation yet.
For the moment, the important discovery is that an address must contain enough structure to tell us not only who the destination is, but also whether it belongs to our local world.
Once knows that is remote, it needs somewhere local to send the message.
A gateway at the edge of the valley We build a special tower at the border of Valley
1.
It can receive local frames from our valley, but it also has a road leading into another network.
Let us call it .
Tower now learns one additional rule: If the final destination is outside Valley 1, give the packet to .
This creates a situation that looks strange only until the two scopes become visible.
Suppose wants to reach .
The final destination is still , but the next tower that can physically receive a local frame is .
The message therefore carries two destinations: Figure
2.
The local frame is an outer delivery envelope addressed to the next hop, .
The packet inside keeps the final destination, .
The outer address gets the message across the current local network.
The inner address survives beyond that network and tells every gateway where the journey should eventually end.
Gateway receives the frame because its own local address is written on the outside.
It removes that local envelope and reads the wider address inside: Now faces the same question that tower faced, only on a larger map.
Where should this packet go next?
A small map inside every gateway We hang a parchment inside : This parchment is our routing table.
It does not describe the complete road from Valley 1 to every tower in the empire. does not need to know every bridge, every mountain pass or every official who will lose the paperwork.
It only needs to know the next useful step.
For , the table selects relay .
If the link between and is another local Ethernet-like network, the wider address of the next hop is still not enough to send a frame. needs the local address of on that link.
This brings us back to the machinery from Part
1.
If the mapping is not already known, asks the local network which MAC address belongs to the next-hop IP address.
In IPv4 over Ethernet, this is ARP.
The forwarding process is therefore not one mysterious act called routing.
It is a sequence of smaller questions: Routing chooses the direction.
ARP, when the current link is IPv4 over Ethernet, supplies the local delivery address needed to take the next step.
The same packet, a new local frame The route across our empire might look like this: On the first hop, the local frame is addressed to .
After opens that frame and chooses the next route, it creates a new local frame addressed to .
Relay repeats the process and creates another frame addressed to .
Inside Valley 2, finally creates a frame addressed to tower .
Figure
3.
The blue end-to-end destination remains .
Each gold local delivery ends at one next hop, after which a new local frame is created for the following link.
The IP destination does not become