This is the fourth post in a series. This posts builds on the previous posts so it is probably best to read them all in sequence. The first post in the series is http://sigma5.blogspot.com/2015/09/internet-bits-bytes-and-numbers.html. The post immediately preceding this one is http://sigma5.blogspot.com/2015/09/internet-ethernet.html. I have posted them one after the other so it should be pretty east to walk your way through all of them. So where are we?
In the second post I devoted considerable time to IPv4 in general and to "local" computers in particular. The third post described Ethernet, the most common way local computers are connected together. This post delves into how remote computers are handled. A key concept to this local/remote determination is the subnet mask. The subnet mask divides the address into a "net" .part and a "subnet" part. It should be already obvious that the subnet mask is important. It may also have occurred to you that we are making things too verbose. Here are some typical subnet masks: 255.0.0.0, 255.255.0.0, 255.255.255.252. That's a lot of verbiage to convey something that is actually pretty simple. So what is being conveyed?
Actually it's a small number. The subnet mask consists of a number of 1s followed by a number of 0s. The number of 1s plus the number of 0s always adds up to 32. So if we know the number of 1s we can instantly calculate the number of 0s. We don't need to keep track of the two numbers separately. The number of 0s is just 32 - "the number of 1s". So we can boil the whole subnet mask business down to one number - the number of 1s. This idea is combined with the network name to compactly convey everything we need to know. Instead of saying something like "the 10.0.0.0 (subnet mask 255.0.0.0) network" we just say "the 10.0.0.0/8 network". The "/8" part indicates a subnet mask of 8 1s followed by 24 0s (255.0.0.0). So we can now say "the 172.16.0.0/16 net" or the "192.168.0.0/24 net" or even, to go back to my complicated example, "the 10.20.0.0/20 net". This makes talking about this sub-netting business much easier. And, once you know the tricks, turning "/20" into 255.255.240.0 is pretty easy. So from here on out I am going to use the "/20" style.
Now let's dive more deeply into the whole process of how IPv4 addresses are handed out. There are 4 billion of them so picking one person or even a small group of people to keep track of all of them is not practical. As I noted before this quickly led to the idea of delegation. A top level group (ICANN) would hand a big chunk to this group and a different big chunk to that group and so on. Let's start by looking at the version of this that was in use for a long time.
It was obvious that some groups needed a lot of addresses and other groups needed not so many. Back in the day when 4 billion seemed like a gigantic number a simple system looked like it could get the job done. So a simple system it was. Well, it was pretty simple system. It was called the "class" system. 5 classes were defined: A, B, C, D, and E. We could now talk about a "class A net", for instance. Sounds pretty simple so far. But of course we have to throw some complexity in. Fortunately it's not that much complexity.
Three exceptions were made to the class system. The 0.0.0.0/8, 127.0.0.0/8, and 255.0.0.0/8 nets were exempted. Two of them make perfect sense. Remember we said that the 0 subnet address is never assigned to a computer. It is reserved for the name of the network. Well, it might have been possible for computers to handle 0.0.0.0 but people got lazy. It was just easy to say "no 0.0.0.0". That simplified a lot of computer coding. And, since we have lots of IPv4 addresses (remember this is the early days), let's just exclude any IPv4 address whose first octet is 0. Similar logic applies to 255.255.255.255". It made lots of computer code simpler if we just said "not going there". And again why not just exclude anything with 255 as the first octet.
That leaves 127. Another trick that turned out to be handy was "how about we have an IPv4 address that is just a way of saying 'this computer'?" For reasons lost to the mists of time the IPv4 address selected was 127.0.0.1. The name generally associated with this IPv4 address is "localhost". And again by the rule of "we have more IPv4 addresses than we know what to do with", any IPv4 address with a first octet to 127 came to be excluded. That's it for complexity. In the original "class" scheme" all other IPv4 addresses conform to the class rules. So what are the class rules?
Class "A" is the giant class. Each class A net consists of about 16 million (the exact number is 16,777,216) addresses. Any IPv4 address with a first octet of 1-126 is a class A net. And the subnet mask for a class A net is /8. So there are 126 class A nets. Together they represent a little over 2 billion IPv4 addresses.
Class "B" is the big class. Each class B net represents about 64,000 (the exact number is 65,536) addresses. Any IPv4 address whose first octet is 128-191 is a class B net. So there are 63x256=16,128 class B nets. And the subnet mask for a class B is /16. Together they represent a little over 1 billion IPv4 addresses.
Class "C" is the small class. Each class C net represents 256 addresses. Any IPv4 address whose first octet is 192-223 is a class C net. So there are 31x256x256=2,031,616 class C nets. And the subnet mask for class C is /24. Together they represent about a half a billion IPv4 addresses.
Class D is the "multicast" class. It appears to be used to some extent but I know pretty much nothing about it. Any IPv4 address whose first octet is 224-239 is a class D net. I don't know enough about class D to talk about subnet masks so you are on your own here. Together class D represents about a quarter of a billion IPv4 addresses.
Class E is the "experimental" class. I know less about this class than I do about class D. Any IPv4 address whose first octet is 240-254 is a class E net. I don't know enough about class E to talk about subnet masks so you are on your own here. Together class E represents about a quarter of a billion IPv4 addresses.
I have long thought that classes D and E should be retired and their IP address ranges repurposed. Together they represent a half a billion IPv4 addresses. That's a lot. But for whatever reason this has not happened. So these addresses are effectively lost. Oh well.
Anyhow, back in the day you would apply for a class A, B, or C net. It was very difficult to get an A, fairly difficult to get a B, and pretty easy to get a C. The company that I used to work for controls 5 class C nets to this day. Big companies like IBM and GE were able to get class As. So was the US military. But it quickly became obvious that handing out class As like jellybeans was a bad idea. So a lot of companies, Microsoft included, opted for class Bs. You had to make your case to get a B but it was pretty easy for any medium sized company to do so. Then the small fry like my old company went for one or a couple of class C nets.
And this system worked pretty well until ARPANET completed the transition to the Internet in the early '90s. (It went through some intermediate transitions like NSFNet that I am going to skip over.) All of a sudden everyone wanted IP addresses. The introduction of Windows 95 by Microsoft accelerated this trend to warp speed. The most obvious response was to replace the "class" system with something more complex.
The old rule was that if you needed more than a few class X nets you were bumped up to the next larger sized class. So my company was ok with its 5 Cs. But what if they needed 30? At about that point they were bumped up to a B. But 30 Cs=7,680 IPv4 addresses. That's only a little over 1% of a Pv4 addresses in a B. That means that more than 98% of the addresses will be wasted. When there were lots of IPv4 addresses to go around that was not a problem. But when things got tight all of a sudden things looked very wasteful. But at the time there was no intermediate step between a C and a B. The obvious solution was to introduce some intermediate steps.
Class A is a /8 net. Class B is a /16 net. Class C is a /24 net. Why not introduce some intermediate sizes like /12 or /20. That was done. Now you could get a net corresponding to any legal subnet mask size. The other change was to make the whole system less US-centric. The Internet was invented in the US. But it spanned the world. Why should it be run exclusively by the US? The Internet quickly got internationalized. ICANN was still top dog. But now the second level was composed of RIRs, Regional Internet Registries.
Well, actually this whole "give out numbers" responsibility was spun off into something called the IANA, the Internet Assigned Number Authority. It took over the whole IPv4 address business. But right under it were 5 regional registries, one for Africa (AFRINIC), North and Central America (ARIN), Asia-Pacific (APNIC), Latin America/Caribbean (LACNIC), and Europe (RIPE NCC). IANA will hand out a big chunk of addresses to an RIR. They in turn will hand out smaller chunks to whoever applies. The combination of all these changes is called CIDR - Classless Internet Domain Registration. CIDR quickly took over for the class system (all unallocated addresses iommediately went into the CIDR pool) but referring to a "class A" or a "class B" or a "class C" net stayed in common usage as short hand for a /8, /16, or /24 net.
And this whole thing has held together pretty well. It has definitely lasted long past the time anyone thought it would. For more see http://sigma5.blogspot.com/2014/09/the-great-internet-disaster.html.
All this has to do with something called "public" IPv4 addresses. You need a public IPv4 address to access the Internet as a whole. A combination of three things have saved us from the internet disaster that never happened. Two of those things are "private" internet addresses and NAT. I will cover them in a future post. The other thing is IPv6. As I have mentioned elsewhere, cell phones (or "mobile" phones as they are called in the rest of the world) use IPv6. A "mobile application", of which there are hundreds of thousands now, is really just the equivalent of a web site on the Internet. But the important thing is that the mobile world is pretty much a universe unto itself. It is possible to access web sites but nobody does it. Why? Because "there's an app for that". So we now have the IPv4 computer/web site world and we have a mostly separate mobile phone/app world. The fact that there is little overlap makes the whole thing work.
But let me spend just a little time on IPv6. An IPv4 address is a 32 bit number. If that isn't enough why not just use more bits? That's the IPv6 solution. Instead of 32 bits an IPv6 address is 128 bits. How big is that? It is 4 billion x 4 billion x 4 billion x 4 billion. Its a really big number. Every time we go through one of these transitions it is more difficult than it was the last time. The idea of going with so many bits is "we don't want to do this again - ever". I think they have succeeded. And in any case I don't expect them to run out of numbers while I'm still alive. And that's a good practical definition of infinity.
So what else changes with IPv6? Not much. The a.b.c.d format got abandoned. It has been replaced by an A:B:C:D:E:F:G:H format. Each number goes from 0-65,536. But instead of decimal numbers they now use hexadecimal numbers. So they go from 0000-ffff. And there is a ".." trick that allows you to drop out a part in the middle if it is all zeroes. But those are just practical changes to make it possible to write and read the giant numbers involved. Other than that, not much has changed. It pretty much works like IPv4. There are some other differences but only the techies will care. They don't make a practical difference to normal people. I will briefly note some of these changes here and there in future posts. But that's pretty much it except . . .
All modern computers are designed to handle both IPv4 and IPv6. Ethernet and other common technologies see messages passing back and forth, just like before. There are a few tiny differences but mostly a message is a message is a message. No changes had to be made to how Ethernet worked to accommodate IPv6. But if you choose to you can have the NIC on your computer have an IPv4 address and a separate IPv6 address at the same time. There are bits in the messages that say "this is an IPv4 message" or "this is an "IPv6" message. The computer sends and receives messages in pretty much the same way in either case. Most application software doesn't even care. If it does there are ways of flagging something to "do this the IPv4 way" or "do this the IPv6 way" but it is pretty much transparent.
Given that traditional computers live in an IPv4 world I recommend turning the IPv6 stuff off. The only exception to this applies to corporate networking people when it comes to some of the computers they deal with. As those people are not the target audience for this post (sorry) I include the following for informational purposes only. This is how it works.
Many companies need to maintain web sites to deal with computer traffic and app servers to deal with mobile traffic. A lot of the business logic will be common to both. You will just "display" things a little differently depending on the device. So it makes sense to host the web site and the app server on the same computer. This is easy to do. And the web site and the app server can then share a lot of code and other application components. This means many features can be implemented once but will apply to both the web site and the app server.
These corporate networking people need to make sure these servers have both a public IPv4 address and a public IPv6 address. It is easy to "bind" the web site to the IPv4 address and the app server to the IPv6 address so they coexist very nicely. If the installation is big enough so that it makes sense to use separate servers then it is still just a matter of making sure app servers have valid IPv6 address. But if it's not part of your app server infrastructure you can do what the rest of us do and just go with IPv4.
Thus endeth, for the most part, the IPv6 tutorial.
No comments:
Post a Comment