This post is the second in a series. To make sense of it you need to either be very familiar with binary and other forms of computer arithmetic or have read the first post in the series. (Even if you are very familiar with binary and other forms of computer arithmetic I recommend you at least skim the first post so you know what's in it.) That post is located at http://sigma5.blogspot.com/2015/09/internet-bits-bytes-and-numbers.html.
The acronym TCP/IP is commonly used. But TCP and IP are actually two separate things. I am going to start with the more foundational and important of the two, IP. IP stands for Internet Protocol. In the computer business "protocol" is a set of rules and formats that let one computer component interact with another one. IP is how computers talk to each other.
The very first computers didn't talk to each other or to much of anything, for that matter. If you wanted to interact with ENIAC, the very first computer, you had to be in the same room with it. And there was only one computer at that time so computer to computer networking wasn't in the cards. But even then there had long existed a technology called Teletype (for a company that made this type of equipment), or sometimes TELEX. The idea was simple. Use the phone system to hook two electric typewriters together. What was typed on one would be printed on the other. The very first computer (and all computers for a long time) was very expensive. So it was obviously a good idea to make it more accessible because that made it easier to keep it busy at all times.
And early computer builders quickly latched on to the idea of hooking teletypes or similar devices up to computers. Thus was born the first computer network. But these early computer networks were "hub and spoke" operations. You had a very expensive computer as the hub and you had teletypes or other kinds of terminal equipment as the spokes. And in the early days there was just one hub, the very expensive computer, at the center. That was fine in the very early days because there were only a few computers around.
Things quickly evolved into quite elaborate networks as computers got more powerful and more of them were built. And even then teletypes could be used to send messages thousands of miles. So computer networks quickly came to span thousands of miles, at least potentially. And it soon came to be that a very few very important people had hookups to two or more computers in their offices. But each computer had its own terminal. For these people it was a hassle to have one terminal for this computer and a different one for that one. So they were interested in a common terminal setup. They also quickly became interested in hooking one computer to another so that data located on one computer could be sent to another.
This was technically feasible even at this early point. You just have one computer look like a teletype to the other one. But by this point computers had ceased to be custom one off devices created by a group of engineers and scientists and paid for by the government. Computers instead had come to be designed and built by private companies. The first successful computer company was Univac. And if there had only been one company that might have been ok. But soon there was also IBM, GE, and many others. And the problem was that for business reasons they all designed hub and spoke networks that could only connect their own brand of equipment.
Then along came the Advanced Research Projects Agency (ARPA) within the Pentagon. By this time the US military had figured out that computers were important for war fighting and they had become frustrated by the proprietary networking technology offered by the companies they bought computers from. So they funded a project called ARPANET. The idea was to figure out how to hook computers from different manufacturers together. The project succeeded, eventually spectacularly. The ARPANET project spawned IP. Well actually, several versions of IP.
There are two versions of IP in use today: IPv4 and IPv6. I am not going to talk about IPv6, although I may do a future post about it. So what do people need to know about IPv4? Some but not that much. And that's what the rest of this post is about.
Computers at bottom are about numbers. So it will come as no surprise (especially since I telegraphed this in the first post in this series) to learn that each computer is assigned a number called an IP address in the IPv4 scheme. This number is 32 bits long, which means that it represents a number between zero and four billion. When IPv4 was designed four billion seemed like a good approximation to infinity. But by the late '90s it no longer looked so big. People started worrying about running out of numbers. I have addressed this subject in a previous post (see http://sigma5.blogspot.com/2014/09/the-great-internet-disaster.html).
In the mean time, what good does our computer having a specific number assigned to it do us? IPv4 is about the business of letting any computer that speaks IPv4 send a message to any other computer that speaks IPv4. And, of course, the other computer can send a message back the other way. The idea is to provide a means for every computer to talk to every other computer. IPv4 does this by including a "from" IP address and a "to" IP address in every message. To respond to a message the other computer just needs to flip the "from" and "to" IP addresses and the new message goes back the other way. It's just that simple.
But how does one computer figure out where the other one is? One idea would be to encode some kind of geographical information. But, as I indicated in my previous post, that wasn't done. An IP address is just a number. There is no geographical information in the IP address. Well, almost no geographical information. I'll get return to this subject later in this post. And I'll go into how a message gets from one computer to another one in later posts. In the mean time let's look at another simple question. How does a computer get an IP address?
The original ARPANET was set up to hook as many as 64 computers together. With only a few computers involved you could just have someone keep a list and assign the next free number off the list. With four billion numbers to keep track of that's impractical. The solution actually adopted was delegation. One super-group of people would assign a big chunk of addresses to a subgroup. This subgroup could slice and dice things further into sub-subgroups each with their own administrators. And this process could go on until someone was responsible for a pool of only a few numbers and a few computers. Then they could assign the numbers in their pool however they wanted. This idea was initially implemented using classes and subnets. Let me start with subnets.
Some of this was telegraphed by the "subnet" discussion in the previous post. But I will now go into more detail. The subnet mask is used to divide an IP address into a "net" part and a "subnet" part. The first part of the subnet mask, the part that is all 1s, is the net part. The rest, the part that is all 0s, is the subnet part. There is a super-group agency out in internet-land called ICANN, the Internet Committee of Assigned Names and Numbers. They are responsible for the bigest chunks. They dole a big chunk to this group, a different big chunk to that group, and so on. And they follow the subnet mask rules. So the big chunk is identified by the first few bits. In the early days the net part was frequently only 8 bits long. So a big chunk might be 10.x.y.z (indicated by a subnet mask of 255.0.0.0). This chunk contains over sixteen million addresses. But the "10 net" owner could then start subdividing. They could give a still pretty big chunk, say 10.20.x.y (indicated by a subnet mask of 255.255.0.0), to a large division within the organization. They, in turn, could give a 256 address chunk, say 10.20.30.x (subnet mask of 255.255.255.0), to a relatively small department. That's a highly artificial example of how delegation worked from a technical point of view.
Above I promised that there was a little bit of geography in IP addresses. The subnet mask rules are taken into consideration when IP addresses are delegated. But the subnet mask primarily fulfills a much more important role. It is used to determine what is "local" versus what is "remote". If the "from" and the "to" IP address are both in the same net then both computers are on the "local" network. In this case the "from" computer just sends the message directly to the "to" computer.
As a specific example, I talked about a "net" with an IP address of 10.20.30.x (our "department" net). We only know what's going on if we can see the subnet mask. In this case it is 255.255.255.0. That means that the "10.20.30" part is the "net" part so the "x" must be the subnet part. How is this sort of thing actually handled? The "0" subnet address is used for the name of the net as a whole. So this would be called the 10.20.30.0 net. Remember that by itself "10.20.30.0" doesn't mean anything. It can only be interpreted after we have applied the appropriate subnet mask.
Here's some supplemental information. To avoid confusion no computer is given the IP address corresponding to a 0 in the subnet part. There is no computer with an IP address of exactly 10.20.30.0. Also, for reasons I am not going to get into, the highest subnet address, 255 in our example, is also left open. So 10.20.30.255 is not assigned to any computer either. This means that the number of IP addresses that can actually be used in a subnet is 2 less than the theoretical maximum. In the example we are working, only 254 addresses would actually be available for use. This need to leave 2 addresses out means that the smallest practical subnet we can have has a mask of 255.255.255.252. This subnet has 4 IP addresses in it. But after we subtract the two we don't want to use there are only 2 left. And that's as small as it gets.
Let's take a slightly more complex example. I talked about a subnet mask of 255.255.240.0 in the earlier post. Let's use it in the context of our 10.20.0.0 network. Why not the 10.20.30.0 network? Look at the third octet. The subnet mask byte is 11110000 but the net byte is 00011110. The binary version of "30" is partly in the net part and partly in the subnet part. This is asking for trouble. What would make sense in this situation? Well, let's say that our organization controlled the 10.20.0.0 net (mask 255.255.0.0). That's a lot of IP addresses but let's assume its a big organization. Now let's say that this organization has divisions and that each division is pretty big, big enough to require in the neighborhood of 4096 IP addresses. Then we could have a 10.20.0.0 (subnet 255.255.240.0 subnet) sub-subnet assigned to "division 0". Why division 0?
Look at the chunk between where the net part for the company ends and where the net part for the division ends. Both net parts share all of the first two octets and none of the fourth octet. But the net part of the company subnet contains none of the bits in the third octet whereas the net part of the division subnet contains the top 4 bits. This middle chunk (the top 4 bits of octet 3) becomes critical. So let's look at them in isolation. (We can ignore the bottom 4 bits of octet 3 for the moment because they are subnet bits in both cases.)
In this critical chunk the bits in 10.20.0.0 are 0000. In decimal that's zero. Now let's flip the bottom bit in our chunk to a 1. Our chunk now looks like 0001 and octet 3 looks like 00010000. In decimal that's 16. So the "division 1" net would be 10.20.16.0 (same subnet mask of 255.255.240.0). Adding 1 again (division 2) we get a chunk of 0010 in binary and an octet of 00100000. Division 3 would have a chunk of 0011 and an octet of 00110000. This translates to a net of 10.20.48.0 (same again on the subnet). We then continue in a similar manner. We can have 16 divisions (0000 through 1111) in total and stick with this scheme.
Finally, notice that 10.20.30.0 falls somewhere in the middle of the address range that belongs to division 1. (Octet 3 would be 00011110). That's why it is a bad choice for a sub-subnet in this scheme. This is a good example of a situation where it's complicated if you just look at the decimal numbers and don't translate to the underlying bits. Welcome to the world of corporate networking. Fortunately there are tricks for avoiding this kind of complexity.
Our local/remote test works the same way in our apparently more complicated situation. But the rule is the same. Two computers are local to each other if they have the same net number. So if our subnet mask is 255.255.240.0 a computer with an IP address of 10.20.48.251 is local to a computer with an IP address of 10.20.61.12. What? It's confusing if you look at the numbers and not if you look at the bits. The third octet tells the tale. In one case the bits are 00110000. In the other case they are 00111101. But we only care about the top 4 bits. In both cases they are 0011 so the net is the same.
So what if the net part is different? That means the two computers are remote from each other. What happens then? Well that's where the gateway comes in. Every network needs a gateway. Usually the gateway has a subnet number of 1 but that's just common usage. The gateway can use any IP address in the subnet. The rule is that gateway address must be a local address. Any computer in the net must be able to send messages directly to the gateway. Why? Because the gateway is the only computer that knows how to access other nets. How? Magic? The slightly more complex (and useful) response is this question will be covered in a later post.
So the trick is a simple one. If a computer wants to send a message to another computer it uses the subnet mask to figure out if the "to" computer is local or remote. If it is a local computer just sends it directly. This means that it must be possible to send a message directly from every local computer to every remote computer. That's one of the things network administrators must understand and get right.
For everything else (the remote computers) the computer just sends the message to the gateway. So network administrators must also make sure that gateways know how to process non-local messages. The format of the message is slightly different. It is marked in a special way that tells the gateway "here's the IP address I really want this message to go to". And, by the way, all gateways have at least two network connections. One is attached to the local network. The others are attached to other networks. If the message is destined for one of those networks then the gateway reformats the message and sends it directly to where it goes. It just gets rid of the special gateway information, leaves the "from" address alone, and changes the "to" address to the correct value. Then it sends it along and it gets to where it is supposed to go.
But what if none of the networks that are directly attached to the gateway are the right one? Then we just go through the gateway thing again. The gateway computer has a gateway entry of its own. It changes the "to" address to this new gateway IP address and sends the message along. If everything is working ok then the message gets a little closer to its ultimate destination. This "forward to the next gateway" process can happen many times. To send a message from the West Coast of the US, where I live, to a computer on the East coast typically takes about 20 "hops".
The Internet is called a "store and forward" network because many of its components get a message in one interface and store it for a very short amount of time. They then decide where it should go next and quickly forward it along to its next stop along the way. Machines that specialize in this "store and forward" functionality are frequently called routers. But gateways function something like a router and routers function something like a gateway. It's a good idea to not get too hung up on the vocabulary.
I think I have probably exhausted you by this point so I am going to stop here. But there will be more installments in the series.
No comments:
Post a Comment