A PC Wakes Up
A STORY BY VICTOR NORMAN
Once upon a time…

a PC (we’ll call him “H”) is connected to a network and turned on.
Aside: The network looks like this:
H needs an IP address

PC H notices he has a network connection, but no name… 

So, he decides he needs to get a name somehow...

He composes a message:

To: Everyone around here

From: me (but, I’m unnamed right now, except this number 0x73.)

Re: I need a name. Is there anyone out there in the network who can give me a
unique name that anyone in the world can use to talk to me? If so, please send me
that name.

(We actually call this a “DHCP request”.)

He sends the message out his network interface.
Meanwhile, on Switch S…

Switch S sees a message on port 1.

Switch S is like a postman: it is responsible for sending messages on
to who they are for, but it never gets messages itself. 

Switch S looks at the To: field and sees this is a special message to
be sent to everyone. So, he makes copies of the message and
sends them out all his other ports.

Switch S also makes a note to itself: I’ve seen a message on port 1
from this guy called 0x73. Now, if I ever get a message for 0x73, I
can send it only on port 1.
Who can handle this message?

The switch has now duplicated the message and sent to everyone.

All machines receive the message, but they look at it, and realize
they aren’t set up to give out unique names to newbies on the
network. So, they throw the message away.

However, NAT N receives the message and realizes that he has
been configured to hand out names to newbies. (i.e., he is running
a DHCP server!)

His DHCP server software looks up information in its config file and
finds an unassigned new name (IP address), and marks that name
as “assigned” to this machine called 0x73.
The Response Awakens


The DHCP server composes a message:

To: you, Mr. 0x73 with no real name

From: me, 10.0.0.1, known around these parts as 0x1a.

Re: Your request for a name

Here is your new name: 10.0.0.3.

Also, everyone on your network is 10.0.0.something, ok?

Oh, and, the DNS server is running on me, 10.0.0.1.

And, if you ever want to talk to someone out in the big world, just send the
message to me and I’ll forward it out there for you.
The DHCP server sends the message, which goes out its network
interface (to Switch S). (Switch says, “Aha! I see a message from
0x1a on port 4. I’ll remember that!”)
I have a name!

Switch forwards the response to H.

H receives the message and from the information knows:

its new unique universal name: 10.0.0.3

That if it needs to talk to any other machine with a name like 10.0.0.*, it
can send to it directly – it is in the neighborhood.

That if it needs to talk to any other machine, it should send the message
to 10.0.0.1, who will handle forwarding the message to the other
machine.

That if it needs to change a name (like www.google.com or
www.cnn.com or calvin.edu) to a computer name (like 153.106.4.1), it
can ask 10.0.0.1 to do the conversion.
Reminder of what our network looks like
Chapter 2: the user wants a web
page

After some time passes… a user starts a web browser on H and types
this into the address bar: http://host2.company.com/index.html.

The browser program knows that it cannot talk to machine with a
nice name like host2.company.com – it has to somehow get the
unique computer name for it (the IP address).

To do this, the program uses a library on the computer. This library
composes a message:

To: name converting server, running on 10.0.0.1

From: me (0x73, aka 10.0.0.3)

Re: convert host2.company.com to its IP address, please. (DNS request)
A funny thing happened on the
way to the post office…

When this library tries to send this message out the network
interface, there is a problem…

The networking code in the OS does not know how to talk to 10.0.0.1
-- it has to have that machine’s local name (which we know is 0x1a).

So, the OS pauses the DNS request message, and generates a
number conversion request (ARP request):


To: everyone in the neighborhood

From: me (0x73, aka 10.0.0.3)

Re: I need the local name of 10.0.0.1
The OS sends this message out its network interface.
What happens next?

What happens when Switch S gets the message?

Answer: it sends it out to all machines.

What happens when each machine receives it?

Answer: it drops the message if it isn’t set up to answer the question.

Which machine can answer the question?

Answer: 10.0.0.1 will answer the question. It will send a response:

To: 0x73 (aka 10.0.0.3)

From: 0x1a (aka 10.0.0.1)

Re: your request for my name: My local name is 0x1a. (ARP response)
And, now back on the farm…

H gets the response (which was forwarded by S).

It forwards it up to the networking code in the OS, which says to
itself:



Huh, so 10.0.0.1 is the same as 0x1a. I’ll remember that (at least for a
while).
It also remembers that it was in the process of sending another
message. As you may recall, the message was:

To: name converting server, running on 10.0.0.1

From: me (0x73, aka 10.0.0.3)

Re: convert host2.company.com to its IP address, please. (DNS request)
Now, the networking code in the OS can send this out, because it
knows the local name of 10.0.0.1 (it is 0x1a).
Finally, the message goes out






The message requesting a name conversion for host2.company.com
has been sent to 10.0.0.1 (0x1a).
Switch S knows where that machine is, so forwards the message to it.
10.0.0.1 (NAT N) receives the message (because it is for it).
It checks to see if it is running the server that resolves names – and Yes, it
is!
This server (DNS server) talks to some other servers and gets the
computer name for host2.company.com (98.1.1.1). The server
composes a message:

To: 10.0.0.3 (aka 0x73)

From: 10.0.0.1 (aka 0x1a)

Re: the request you sent for a name conversion.

I have found the computer name for host2.company.com. It is 98.1.1.1.
Have a nice day!
It sends the message out its network interface, via S, to H.
And, back on the farm again…

The name conversion response is received and sent by the OS to the
library that requested the name conversion.

The library says to itself:

“Huh. So host2.company.com is the same as 98.1.1.1. I’ll remember that for
a while. Could come in handy again.”

The library now tells the web browser that it got the computer name it
needed.

The web browser software now makes a new request to send over the
network to 98.1.1.1:

To: 98.1.1.1

From: 10.0.0.3 (aka 0x73)

From-Mailbox: 37373 (this mailbox was randomly chosen and not in use)

Re: web page request. (Mailbox: 80)

Please send me the file index.html. Thanks.
But, whoa!

We have a problem. A computer can only talk to its neighbors, and
98.1.1.1 is not a neighbor – it is some machine somewhere out there in
cyberspace.

Fortunately, the networking code remembers something:



“If I need to talk to any other machine, I should send the message to
10.0.0.1, who will handle forwarding the message to the other machine.”
So, it changes (or really, amends) the message slightly:

To: 98.1.1.1 (via 10.0.0.1)

From: 10.0.0.3 (aka 0x73)

From-Mailbox: 37373

Re: web page request. (Mailbox: 80)

Please send me the html file index.html. Thanks.
This way, the message is marked as ultimately for 98.1.1.1, but locally for
10.0.0.1.
Still no go…

We have this message:

To: 98.1.1.1 (via 10.0.0.1)

From: 10.0.0.3 (aka 0x73)

From-Mailbox: 37373

Re: web page request. (Mailbox: 80)

Please send me the html file index.html. Thanks.

But, how do we talk to 10.0.0.1. We know he is on the local network, so
we can talk to him. But, we need his local name, not his global name.

Wait! Remember we made a note to ourselves earlier:


“Huh, so 10.0.0.1 is the same as 0x1a. I’ll remember that (at least for a
while).”
So, we replace the first part of the message with this:

To: 98.1.1.1 (via 0x1a). Now we can send the message.
And, away we go!

The message goes out H’s interface.

Switch S sees it and knows to forward it out only port 4 to 0x1a
(10.0.0.1).

NAT N receives it (because it is for 0x1a – itself).

N notices that it really isn’t for itself – it is for 98.1.1.1.

N has been told previously that for messages it doesn’t know how to
deliver, it should send them on to Router R (201.202.203.1).

However, N is a NAT (Network Address Translation) device… so it is
special.
Reminder of what our network looks like
Far from the NATting crowd

A NAT is special. It is like agent 007. It keeps secrets.

A NAT passes messages from one side to the other, not letting either
side know what it is doing.


Specifically, it keeps the “private side” (10.0.0.*) network secret from the
world.

The world just thinks it is communicating with the NAT. The NAT is
actually passing the messages on to the private network.
How does it do this?
How to be a secret agent

To: 98.1.1.1 (via 0x1a)
 changed to (via 0xb0)

From: 10.0.0.3 (aka 0x73)
 changed to 201.202.203.204 (aka 0xfa)

From-Mailbox: 37373
 changed to 40000 (randomly chosen)

Re: web page request. (Mailbox: 80)

Please send me the file index.html. Thanks.

So, now the message that goes out seems to come from N itself, not
from 10.0.0.3. N sends the message out to R (local name 0xb0).

N remembers this:

if I get a response to me (201.202.203.204) to Mailbox 40000, it means
the message isn’t actually for me. I should instead forward it on to
10.0.0.3, Mailbox 37373.
On the road again…

The message arrives at R (because it is marked as being for 0xb0).

R sees that it isn’t for itself – it is actually for 98.1.1.1.

R has been configured (somehow!) to know to send the message
out its 77.1.2.3 interface, in order to get it to 98.1.1.1.

R does that.

Repeat some number of times… until the message arrives at 98.1.1.1
(local name 0x3a).
Are we there yet?

The message is at the intended recipient host2.company.com.

The message is accepted and the networking software sees that it is
sent to Mailbox 80.

The software sees that a web server is waiting for messages on
mailbox 80, so it gives the message to that program.

The web server looks at the request, which is:


Please send me the file index.html. Thanks.
The server finds the file index.html, wraps it up nice and neat, and
begins to compose a response:
An answer

To: 201.202.203.204

From: 98.1.1.1 (aka 0x3a)

To-Mailbox: 40000

Re: response to your web page request (from Mailbox 80)

Here is your web page:

<head><title>A web page</title></head> …. etc ....

The networking software looks up how to get the message to
201.202.203.204 and sees it has to send it to a local machine which
will take care of getting it there. The software also puts the local
name of the machine in the To: field above.

The message gets back to N.
And then…

N receives a message to itself, mailbox 40000.

It remembers that this is actually for 10.0.0.3. So, it changes the
message:

To: 201.202.203.204
 changed to 10.0.0.3, aka 0x73

From: 98.1.1.1 (aka 0x3a)
 changed to (aka 0x1a)

To-Mailbox: 40000
 changed to 37373

Re: response to your web page request (from Mailbox 80)

Here is your web page:

<head>A web page></head> …. etc ....

Thus, the message appears to 10.0.0.3 to have been created by
98.1.1.1 and unaltered.
Chapter 3: We are done

The message arrives at H and H accepts it.

It passes the message to the web browser who is waiting on mailbox
37373.

The web browser sees it is a good response and translates the HTML
into a web page and displays it.
What we didn’t talk about…

What happens if your message becomes corrupted, or lost, or
hijacked by a hacker?

Why does a machine have two or three names:

Local name (0x1a)

Global computer name (98.1.1.1)

Global human-readable name (host2.company.com).

Many many other details…

Will this be on the test?