Two Names for One Machine

Your machine has two names. One was burned into its network card in a factory, and it looks like a4:83:e7:2b:91:0c. The other was handed to it when it joined the building’s network, and it looks like 203.0.113.9. Frames on the wire carry the first kind in their header, and the content inside those frames carries the second kind. Switches forward by the first. Routers forward by the second.

If this seems like one name too many, you are in good company. It is the most common confusion people carry away from their first encounter with networking, and it tends to persist for years, because the usual explanation is a diagram of layers with the two names in different boxes and no account of why there should be two at all. So let’s do the why properly. It takes less room than you might expect.

Try throwing one away. Keep the location name, since it is the useful one, the one with structure, the one routers can summarise, and get rid of the factory name entirely. Every frame now carries an IP address in its header and nothing else.

Now plug a brand-new machine into Mira’s building. It needs an IP address, and it does not have one, because IP addresses belong to buildings and this machine has never been in this building before. Somewhere on the building’s network there is a machine whose job is to hand out addresses, and the new machine needs to ask it. So it sends a frame, and we come to the question of what goes in the source field.

Nothing goes there. The machine has no name. We threw the factory name away, and the location name is what it is asking for. The frame goes out with a blank return address. The machine that hands out addresses receives it, prepares an answer, which is that you are 203.0.113.42, and has nowhere to send it. It could broadcast the answer, but every other machine on the network would receive that broadcast too, and none of them could tell whether the answer was meant for them, because the only thing that distinguishes the asker from everyone else is the name it does not yet have.

This is the circularity from Chapter 4, back again and unresolved. To be given a name, you must be able to receive a message. To receive a message, you must have a name.

Now you can see why Chapter 4 decided the way it did. The factory name breaks the loop. The new machine sends its request with a4:83:e7:2b:91:0c in the source field, a name it has always had, assigned before the machine was ever plugged in anywhere, and it addresses the request to everybody, since it does not know who hands out addresses here. The address-giver receives the request, prepares the answer, and sends it to a4:83:e7:2b:91:0c. The new machine receives it, and it now has a location name.

The identity name exists so that a machine can be spoken to before anyone knows where it is. That is the whole reason. It is not that two naming systems are tidy, or that a diagram of layers demands it. A machine with no address needs some name in order to be given one, and the only name it can possibly have at that moment is one that was assigned without reference to where it would end up.

The mechanism by which a machine asks the building for an address, and is given one along with its mask and its gateway, is called DHCP. You have watched it happen every time a laptop joined a Wi-Fi network and took a second to become useful. That second was this exchange. The shape of the answer is worth keeping in mind through the rest of the chapter: one name is for being addressable at all, and the other is for being findable from anywhere.

So the two names divide the labour. The identity, the factory name, is permanent, globally unique, and structureless. It says who the card is. It works on the local wire without any setup, because it needs none, and it cannot be routed, because it encodes nothing about location. The location, the IP address, is temporary, assigned on arrival, and hierarchical. It says where the machine currently is. It can be summarised and therefore routed, and it cannot be used until it has been assigned, and assigning it requires the identity. Neither can do the other’s job. Take away the identity and nothing can be bootstrapped. Take away the location and nothing can be forwarded past the first switch. Both survive because both are necessary, one to start and one to travel.

Now consider the other direction. Your machine has both names and wants to send a frame to Mira, who is on the same wire. It knows her IP address, 203.0.113.7, because that is how humans and programs refer to machines. But the frame on the wire needs her identity in the destination field. The switch forwards by identity, and the card filters by identity. At this level the IP address is just content. Your machine has a location name and needs the identity that goes with it, and the question is how it finds out.

It asks the room. It builds a frame addressed to everybody whose content says, in effect, whoever has 203.0.113.7, tell me your identity. Every card on the wire receives it. Every machine looks at the address in the question and compares it to its own. Mira’s machine sees a match and replies, directly to your identity, which was in the source field of the question, that 203.0.113.7 is a4:83:e7:2b:91:0c. Now your machine can build the real frame, with her identity in the header and your message in the content.

This exchange is called ARP, for address resolution, and it is the glue between the two names. David Plummer wrote it down in 1982, when the machines at MIT had acquired their second name and needed a way to get from one to the other, and it has the same shape as the DHCP exchange run the other way: a broadcast question and a directed answer.

You would rather not do this before every single frame. Asking the room is cheap but not free, since it interrupts every machine on the wire, and the answer does not change from one frame to the next. So your machine remembers it. The first time it sends to Mira, it asks; after that, it looks the answer up in a little table it keeps and skips the question.

Before we get to what goes wrong with that table, there is a picture to have in your head, because it settles the confusion for good. Think of the frame as an envelope and the content inside it as a letter. The letter has Mira’s IP address on it, her location, the thing that says which building she is in. The envelope has an identity on it, a name that is meaningful only on the wire the envelope is travelling on at that moment.

When Mira is in your building, the envelope is addressed to her identity and the letter inside is addressed to her location, and both name the same machine. When Mira is in a different building, the letter inside is still addressed to her. Her IP address is what you want to reach, and it does not change. But the envelope is addressed to the router, because the router is the machine on your wire that can get the letter closer. Your machine does not ask the room for Mira’s identity at all, since Mira is not in the room. It asks the room for the router’s identity, puts that on the envelope, and puts the letter, addressed to Mira, inside.

The router receives the envelope, opens it, reads the letter’s address, and consults its table. Building 12 is across the courtyard. So it puts the letter in a new envelope, addressed to whichever identity is next on that side, which is Mira’s own if her building is directly across, or another router’s if there is more than one hop, and sends it on. The letter is untouched. The envelope has been replaced.

loading…

The location name travels end to end, and the identity name lives for one hop. Every diagram of every network you will ever see is a picture of that sentence. Once you have it, the two names stop being confusing and start being obvious: naturally you need one name for the whole journey and a different name for each leg of it.

Back to the table your machine keeps, the one that remembers that 203.0.113.7 is a4:83:e7:2b:91:0c so that it does not have to ask. Mira’s network card dies. She buys another one and plugs it in. It works immediately; her machine asks the building for an address, and because the address-giver recognises her machine, it gives her the same one, 203.0.113.7. From her side nothing has changed. Same address, same building, same everything.

But the new card has a new identity, since it came from a different factory batch, and your table still holds the old one. Your machine wants to send to 203.0.113.7, looks in the table, finds an answer, and confidently addresses the envelope to a4:83:e7:2b:91:0c. That identity no longer exists. The switch has not seen it since the old card stopped, so it copies the frame to every socket in case someone answers. No card answers. The frame goes nowhere, and nothing reports that it went nowhere.

Your table is not broken. It is stale. The answer it holds was true when it was written and is false now, and nothing told it.

There is an obvious fix, which is not to remember answers forever. Give each entry in the table a lifetime, and when the lifetime expires, throw the entry away and ask the room again the next time it is needed. The question is how long the lifetime should be. Make it short, a second say, and you are asking the room constantly, which is what the table was meant to avoid. Make it long, an hour say, and after Mira swaps her card you are addressing frames to a ghost for up to an hour. There is no lifetime that is right. There is only a trade between how much asking you are willing to do and how long you are willing to be wrong.

loading…

You will pick something. A minute or two is what real machines pick, and it will be wrong occasionally, and that is the honest outcome. What matters more than the number is that you have just met a pattern, and you should learn to recognise it on sight. A cache is a copy. Copies go stale. The only question is how long you are willing to be wrong.

This little table of identities is the first cache in the book, and its failure is the first instance of staleness. It will not be the last. Several floors up, a table of human-readable names will go stale in the same way, and you will be choosing a lifetime for it with the same trade-off. Higher still, a copy of a database will lag behind the original, and Mira will be told that her own photo does not exist because the copy had not heard yet. Higher again, a copy of a video on the far side of the world will remain the old version for as long as you told it to remember. Every one of those is this chapter’s table at a different scale. Every one will have a lifetime, and the lifetime will be a choice about being wrong.

Six chapters in, the tower has a shape. Frames have edges, they carry a check, they name their destination and their source, machines have a location as well as an identity, and there is a way to go between the two. A message from your machine can reach any machine in any building whose location you know, and the boxes in the middle need only know about buildings.

What you have not dealt with is anything above the machine. Every frame so far has been addressed to a computer. But a computer is not the thing you are talking to. A computer runs a dozen programs, and only one of them is the one you meant.

Coming up · I·7 — Which Program?

The frame reaches Mira’s machine. Her operating system now holds some bytes and has no idea which of her programs they are for.

→