This is the fifth post in this series. I recommend reading them in sequence. The first one is at http://sigma5.blogspot.com/2015/09/internet-bits-bytes-and-numbers.html. The immediately previous post is at http://sigma5.blogspot.com/2015/09/internet-classescidripv6.html. In this post I am going to attack two subjects. The first is how routing works on the public internet. And the second is NAT - Network Address Translation. The two subjects turn out to be interconnected. Onward.
I have touched briefly on the subject of routing in an earlier post. Two computers are local, in the IPv4 sense, if they are both in the same "net". You apply the subnet mask to the computer's IPv4 address and extract the net part. You do the same thing to the IPv4 address of the "to" computer, the one the message is being sent to. If the net part of both IPv4 addresses is the same then the computers are local and the message is sent directly to the "to" computer. Any IPv4 address that is not local is, by definition, remote. What happens in this case, as far as our computer is concerned, is simple. The message is just sent to the gateway. But what does the gateway do?
Theoretically there this specific thing called a "gateway" and there is this other different specific thing called a "router". As I have pointed out in several places previously, roles now frequently get mixed together in the modern Internet. That's true of gateways and routers. A router's job is to route messages along toward their destination. It turns out that, to some extent, a gateway does the same thing.
All gateways have at least two interfaces. One is connected to the local net so that it can catch traffic that is intended specifically for it. But that same interface also catches gateway traffic. Once the gateway has caught the message, which is marked as a gateway message, it does its gateway thing. First it looks at its other interfaces. There may be several but, in most cases there is just one. Each of these other interfaces has a net associated with it. Let's say the message destination is within that net. Then the gateway gets rid of the extra gateway stuff in the message and sends it directly to its destination using the appropriate interface. But what if there is no match? Then, if the box is actually just a simple gateway, the box looks up its own gateway address and forwards the message along.
Now consider a pure router. It typically will have several interfaces. Again each will have a net associated with it. If the "to" of the message is a match to any of these interfaces it behaves just like the gateway. It strips off the gateway stuff and sends it directly on to its destination. So far that's just the same as a gateway. But what if we have a miss? What if the "to" IPv4 address doesn't match anything. Then what? Here is where router behavior differs from gateway behavior. A router has a routing table. The routing table has a bunch of net-like entries. The entry says something like "if the 'to' IPv4 address fits the net specification for this entry send the message out interface 4". A properly constructed routing table has at least one entry that matches any IP address.
There are some special ones that say "If you match this entry just throw the message away". These entries are used to handle 0.0.0.0/8, 127.0.0.0/8, 255.0.0.0/8 and other similar cases. There is usually a "default gateway" type entry that says "if you otherwise don't know where to send it, send it here". But basically what a router does is get a message, look it's "to" IPv4 address up in the routing table, and send it out using whatever interface the routing table specified. That's it. But how does the routing table get set up and maintained? That's where the magic is.
There are a number of "discovery" protocols used to create and maintain routing tables. Each router knows what nets it is directly connected to. It plugs that information into its routing table. But it can also use one of these protocols to send the information to all the routers it is in contact with. And yes, there is a protocol for routers finding each other. More than that, a router builds up information on what its nearest neighbor routers can access. It sends that along too. And so on. So a router can eventually find out what routers 3, 5, 10, etc. hops away have access to. The details of the several systems for doing this vary but they all perform the same basic function. Special procedures have to be used when one router uses one system and another router uses another. But that too has been worked out.
So theoretically we wait a while and the router knows where everything on the Internet is. But the Internet is redundant so there are usually two or more paths from point A to point B. Each of the routing table maintenance systems uses a different "weighting" system. A simple "metric" is hop count. If the destination is three hops away using one path and two hops away using another path, go with the shorter path. The weighting function can get quite complex but that gives you the idea.
And that's how the Internet actually worked before it became the Internet. Back then the federal government owned it all and paid for it all. There was no particular reason to prefer one route over another so the systems just fought it out and as long as the message got delivered everyone was happy. But now all the pieces of the Internet are in private hands. Companies want to minimize costs and maximize revenue. All of a sudden path B might look a lot better to the bottom line than path A. So a lot of the components of the old system are still in place but a lot of biases have been added in to make sure the answer comes out the way the company wants it to.
Routing tables are no longer just built automatically by using some kind of discovery process. A lot of manual effort now goes into their construction. And the details of their construction are closely guarded secrets. So I don't think anyone now knows all the details. But here's a guess that I think is pretty close.
Let's construct a simple model of the Internet. You have your local network, say at home or at work. For the moment we will assume that all your computers have "public" Internet addresses. (I'll get into what that means below.) So you have some computers on a local net using Ethernet. One of these computers is the gateway. The gateway has two interfaces. One is connected to your local network. The other is connected to an ISP, an Internet Service Provider. If the message is going to another computer in the ISP's coverage area the ISP shoots it over to that other gateway and it disappears into the local network where it is delivered.
But let's say the "to" computer is in the control area of a different ISP. For simplicity sake, I am going to assume that other ISP is not directly connected to our ISP. In this case the ISP passes the message along to what I am going to call a long haul service provider. There are a number of these LSPs and the actual situation is much more complicated but stay with me. There are routers all over the place. Some belong to one LSP. Some belong to another. The LSP's job is to see that everything gets delivered. But the more traffic he can dump on to some other LSP's equipment (routers, long haul Internet circuits, etc.), the lower the first LSP's costs are. But then, to make things complicated, there are companies like Netflix that are willing to pay for premium service. So we have competing agendas.
What happens is that the ISPs and the LSPs have people called traffic managers. Their job is to firstly make it all work. But beyond that they need to arrange things in the manner most advantageous to their employer. So they spend a lot of time figuring out what path is the "best" (for their employer's objectives) path. They then ship out routing table data to make it so.
You can see this kind of thing in action for yourself. I did some experimenting with a command called TRACERT. It tells you the names of all the routers in the path between "from" and "to. If I trace the route of a message to Boston College a company called Level 3 ferries the message across country. But a message to the University of Massachusetts, a school located in the same city, uses Northern Telecom. Why?
My theory is that the ISP that Boston College contracts with subcontracts its long haul needs to Level 3. Whereas the ISP that U Mass contracts with subcontracts its needs to Northern Telecom. Am I certain of this? No. But What I do know is that two messages going to almost exactly the same place take wildly different routes. And, by the way, all traffic to the same destination seems to always take exactly the same route.
I also know that routing tables have gotten extremely complicated. There was an outage a year or so ago that was caused by some routing tables exceeding an approximately 30,000 entry limit. I also have a neighbor that does this kind of thing for one of the telephone companies. He has told me a couple of war stories about tweaking certain traffic to go this way instead of that way. Why? Because somebody was writing a big check to his employer.
Anyhow the magical thing is that somehow it works. The routers with their routing tables do get out messages wherever we want. And "wherever" can be anyplace in the world. It's pretty magical. And fortunately we don't have to have anything to do with routers or routing tables. That's definitely something to be grateful for. And that brings me to NAT.
Your little home network and mine don't actually use public IPv4 addresses. They use private ones. Let's start out with the basics. Fortunately for us someone came up with a brilliant idea a while ago. "Let's carve out some special IPv4 nets", this person said. These nets will be specifically designed to NOT work on the public Internet. Instead they will be "internal use only" nets. The official name for these babies is private IPv4 nets. Since these nets don't work on the public Internet they can be used over and over. You don't need to worry if someone else is already using the net you want to use. Their use does not interfere in any way with you using the exact same private net.
And at least one net was set up for each "class" size. So we can pick which private net to use in a specific situation based on how many IPv4 addresses we need. This was done back in the old "class" days so these reserved private nets follow the old rules. The private nets are:
Class A - 10.0.0.0/8 (1)
Class B - 172.16.0.0/16 through 172.31.0.0/16 (16)
Class C - 192.168.0.0/24 through 192.168.255.0/16 (256)
Many home networks, including mine, use 192.168.0.0/24. The company I used to work for uses a number of class C private nets but it also uses several class B private nets. (It pretty much doesn't use its public class C nets at all but it turns out to be hard to give Cs back.) These IPv4 nets are carefully selected because they don't work on the public Internet. But many of the devices using these private addresses need and get access to the Internet. How is all that possible?
The answer is NAT. And to understand what is going on you need to know a little more technical detail. When you send a message to a computer you don't just simply send it to that computer. You send it to a specific port that belongs to a specific protocol type. That's the foundation of the trick.
There are several protocol types. But the only ones we care about are UDP and TCP. (Now we finally get around to the discussion of TCP I promised you in the second post in the series.) The protocol rules for the two are different. TCP is like making a telephone call. You set up the call (dial - answer). Then you talk back and forth. When you are done you both hang up. TCP works the same way. You set up a session. Then you exchange messages. Then you tear down the session. TCP also makes sure the messages are delivered and in the correct order.
UDP is often called a "datagram" service. It is like exchanging telegrams (or, in the modern era, Tweets). Each message is a stand alone entity. It has to have a full set of from/to information. And there is no guarantee a message will be delivered or, if two messages are delivered, they will be delivered in the correct sequence. There are advantages and disadvantages to each. The point is that each computer has a set of 64,000 TCP ports and a different set of 64,000 UDP ports. A message not only goes to a specific IPv4 address but it goes to a specific port belonging to a specific protocol type. If any one of these three things is different (IPv4 address, protocol type, port number) it is a path to a different place.
NAT takes advantage of this. Your NAT box has two interfaces, an "outside" interface and an "inside" interface. Let's say you have one public IPv4 internet address. It gets attached to the outside interface. Then an IPv4 address from your private network is attached to the inside port. And, by the way, your NAT box is also your gateway box. So now your computer, which has a different IPv4 address, one from your private network, is hooked to your internal network. And lets say all the boxes on your private network are connected together using Ethernet technology. This is all probably sounding pretty familiar by now.
So you want to send a message, say a Google query from the browser on your computer. Well, that message needs to get to the Google server somehow. What happens? Well, Google's server is not on your local net so the message gets sent to the your gateway, which also happens to be your NAT box. The message comes in on the inside interface and is marked as a gateway situation. It is also marked with the eventual destination of Google. And it's a web message. That means it uses the TCP protocol type and it is supposed to go to TCP port 80. (I know this because the Internet has all these "well known" things and I know where to look them up.) But the point is that the NAT box knows that your computer generated a TCP message from port 80 on your computer to port 80 on the Google computer.
What it then does is pick a different TCP port on its outside interface and fix the message up so that that it looks like exactly the same TCP message came for this other port number and from the outside interface's IPv4 address. It still sends it to the Google server and to TCP port 80. It also remembers that it made this specific translation for this specific session. When the response comes back from the Google server it is addressed to the IPv4 address of the external interface of the NAT box. It is also addressed to a specific funny TCP port on that interface. The NAT box looks all this up and says "Oh - I need to translate things back so that the message goes to the IPv4 address of your computer and to TCP port 80". So a fixed up version of the message from Google shoots out the NAT box's internal interface destined for your computer.
The NAT process is "stateful". It keeps a lot of specific information about the state of each connection. And it maintains separate state information for each connection. This way it can handle multiple web sesstions at the same time or multiple sessions of different kinds from the same computer. The entire process is very complicated. Fixing everything up so nobody is the wiser can be very complicated in some situations. Newer protocols are now carefully designed so that they are easy to NAT, the complexity of the translation process is kept to a minimum. But that's the basic idea.
The NAT box is able to fix everything up so that all the traffic in the public part of the Internet appears to come from the same single public IPv4 address. Computers on your local network think they are talking directly to the boxes out on the Internet with nothing funny happening along the way. What makes all this possible is that there are tens of thousands of port numbers available and that only a few of them are in use at any one time.
And the best news of all is that all this complexity is taken care of for us by the NAT box. You just turn it on and it magically works. And what NAT has done is to drastically reduce the need for public IPv4 addresses. I have a number of different kinds of boxes at home. Most of them need Internet access at least once in a while. This is all easily accommodated by my home NAT box (which is also an Ethernet switch) so everything works fine even though I only have one IPv4 address available to handle all of it.
My old company actively uses several public IPv4 addresses. But they had more than 1,500 devices when I retired, and that was several years ago, and a goodly percentage of them needed Internet access, at least occasionally. And the same is true up and down the line. NAT boxes and private nets are now the norm. It has gotten to the point where they are often more convenient than using public IPv4 addresses would be. By switching to NAT and private networks Microsoft was able to abandon at least one class B so that it could be added back to the CIDR pool.
A final note on these private nets. Above I indicated that routers have routing table entries that throw traffic from certain nets like 0.0.0.0/8 away. Well, they also have "throw it away" entries for the private net addresses. There is an entry for 10.0..00/8 and for 172.16/0.0/12 (check it out - it catches all of them in one entry) and for 192.168.0.0/16 (same here).
And a quick note on IPv6, things work in pretty much the same way as they do with IPv4. But the Internet handles IPv4 and IPv6 traffic separately. It may go down the same wire and it may be processed by the same router. But both the wire and the router behave pretty much like they are two wires and two routers. There is separate logic in the router for handling IPv4 and IPv6 traffic. The general approach is the same and both kinds of traffic may come in or go out on the same interface but the two routing tables are completely separate. Inside the router the traffic is completely segregated.
There's not much in this post that average people will use. But I hope it clears up how things work and provides some perspective that is helpful when wrestling with the parts of networking that you are forced to deal with.
No comments:
Post a Comment