Advanced TCP/IP

9/1/11 11:34 AM

Advanced TCP/IP

I mentioned earlier that certain network numbers are "special", and that they would be bad choices. You may also realize (or need to know) that if the machines you are assigning numbers to are connected directly to the Internet, without going through a firewall or router that is translating or otherwise proxying network addresses, the choice of numbers isn't up to you at all. That's because the IP addresses used on the Internet are specifically asigned to the people who own them: you can't just grab any arbitrary number out of a hat and use it. You have to get your own assigned IP addressees. However, most small business networks either are not connected at all, or will be connected through a NAT (Network Address Translation) router or through a proxy firewall. It's a little too early to discuss either of these subjects, so let's just move along with you happily assigning your own IP addresses.
In many companies, IP addresses are assigned automatically by a DHCP (Dynamic Host Configuration Protocol) server. Still, somebody has to tell that server what addresses to hand out.

First, you can't use 127 as the first number. This is because the address 127.0.0.1 is reserved as a "loopback" address; an address that always refers to the machine at hand. In other words, every machine on your network can telnet to 127.0.0.1 and they will always end up at themselves, and not anywhere else. What's the point? Actually, it's useful. Consider the case of a client-server application where you want to run the client on the same machine as the server. Or consider a programmer who wants to test a network program, but doesn't want to go out on the real network just yet.
http://aplawrence.com/Unixart/advtcp.html Page 1 of 9

Advanced TCP/IP

9/1/11 11:34 AM

You also may have had support people ask you to "ping 127.0.0.1" to test your TCP/IP configuration. What's being tested there is strictly TCP/IP, with the network card not in the loop, and no interference or confusion from the rest of the network. It's strictly local, strictly a loopback. It needs to be there: don't ever delete this address from /etc/hosts. The next addresses you shouldn't use are anything beginning with 224 or above. These are the Class D and Class E addresses (that's old terminolgy, but people still use it, so will I), reserved for special use. One use being made of them now is for Multicast addresses, where one computer sends data but many other computers receive it. Just about anything else is available to you, following the rules that none of the four numbers can be 0 (really, some of them could be zero, but it's less confusing right now if we pretend that they cannot) and none of them can be 255. Keep in mind that the rules about 127 and 224 and up only apply to the first number of the four: you shouldn't use 225.10.1.8, but 10.225.1.8 is fine. By the way, these four numbers are usually referred to as "octets", simply because they hold numbers that can be expressed in 8 bits. If it makes your head hurt to talk about bits, this might be a good time to bail out, because we're going to be getting into that pretty heavily from this point on. On the other hand, I'm going to try to make it painless, so you might consider hanging in there. Don't panic, but we're going to talk bits! An eight bit number can be anything from 0 to 255. This is because of the value of the
http://aplawrence.com/Unixart/advtcp.html Page 2 of 9

Advanced TCP/IP

9/1/11 11:34 AM

bits. The 0 bit (computer geeks number things starting with 0, not to annoy you, but because it's easier when working with low-level computer registers) is worth 1 if set (and 0 if not), the 1 bit is worth 2 (again, if set, and zero if it isn't), the 2 bit is 4, and so on. Usually that's illustrated something like this: In this case, since bits 7, 4, and 1 are checked. the value would be 128 + 16 + 2, or 146. Let's try a different one:

Here, we have bits 7, 6, 5 and 4 checked, so the value would be 128 + 64 + 32 +16, or 240. If all 8 bits were "on", that would add up to 255. Confused yet? Note:If your browser can do Javascript, you might like to play with a Javascript Bit Twiddler What do you think it might mean if I said the subnet mask was going to be 255.255.255.0? Yes, it would mean that all bits in the first three octets are set, or "on". If I said it's 255.255.240.0, it would (of course) mean that all bits in the first two octets were set, but only the leftmost 4 bits (the "high order" bits) were set in the third octet. Now, I said before that where ever you see "255", that means you can't change that part of the network numbers without ending up on a different network. So, 10.1.35.12 with a mask of 255.255.255.0 is on a different network than 10.1.68.12 (the first network is 10.1.35.0 and the other is 10.1.68.0), but if the mask were 255.255.0.0, those machines would be on the same network (the network is 10.1.0.0). So what if the mask is 255.255.240.0? What I hope you are thinking right now is "Oh, it isn't the "255" that's magic, it's the bits that are set". If that is indeed what you were thinking, that's good, because you are correct. It's the bits that are important, and the "240" means that the network portion of the address (the part you can't change without changing to another network) is 4 bits bigger than it would be otherwise.
http://aplawrence.com/Unixart/advtcp.html Page 3 of 9

Advanced TCP/IP

9/1/11 11:34 AM

So what network is 10.1.35.12 part of if the subnet mask is 255.255.240.0? The important number here is "35". Let's look at the bits:

32 + 2 + 1 = 35. So the "network" part of this address is actually 10.1.32.0. The "32" that's part of the "35" is within the network portion. Why? Because the netmask ending in 240 only runs through the 16 bit (128 + 64 + 32 + 16 = 240). So everything to the right of the 16 bit belongs to the host, not to the network. Therefore, this is host 3.12 on network 10.1.32.0. Why host 3.12? Because those are the host bits. The "35" is made up of "32" (which belongs to the network part) plus "2" and "1" (which is "3" that belongs to the host part of the address- the bits that fall outside of the netmask). Got it? Now let's look at the other address. Again, I hope it's obvious that the "68" is the important part, because that's the octet that has a partial (not 255) mask:

So, 10.1.68.12 is on the 10.1.64.0 network, which is different than the 10.1.32.0 network. This is host 4.12 on network 10.1.64.0. What's on this network? How can you assign another address that is on the 10.1.68.0 network? Just as before, by not changing any of the numbers that are "covered" by the bits of the subnet mask. So, we can change any of bits 0 through 3, but not the "64" bit. Therefore, we end up with anything from 10.1.65.xxx (the xxx can be anything from 1 through 254) to 10.1.78.xxx, plus part of 10.1.79.xxx. Here's what "65" and "78" look like:

http://aplawrence.com/Unixart/advtcp.html

Page 4 of 9

Advanced TCP/IP

9/1/11 11:34 AM

The addresses 10.1.65.2, 10.1.73.2, and 10.1.78.223 are all on the same network (again, remembering that our subnet mask is 10.1.240.0). The numbers have changed (65,73,78), but the network part (the 4 bits that represent the network) hasn't. It's really just bits If you are really paying attention, you might ask "What about 79?". The answer is that the rule we learned before about not using "255" also has to do with bits, and not with something magic about "255". With this mask (255.255.240.0), "10.1.79.255" would mean that the address portion was "all bits set", and that (as we'll learn later) is a "broadcast" address. This gets really confusing. It's actually simple; just bits set or not set, but since we humans don't think that way, it's hard for us to see what's going on easily. Strangely, for this subnet, 10.1.73.255 would technically be legal, even though it looks like a broadcast address on the 10.1.1.0 network. It isn't, though, because the network is actually 10.1.64.0, so the broadcast bits are not set. But for 10.1.79.255 on 10.1.64.0, the broadcast bits would be set. Let's look at the bits:

That's "73"

and that's "79". In both cases, the network part is the "64" bit, and the rest is address. When the final octet is "255", the 10.1.73.255 does not have all of it's address bits set to 1; bits 1 and 2 are not set in the third octet. But with 10.1.79.255, everything in the address part is set (the "address" part is all the bits that are not in the "network" part).

http://aplawrence.com/Unixart/advtcp.html

Page 5 of 9

Advanced TCP/IP

9/1/11 11:34 AM

Life is confusing enough without this! I wouldn't recommend using those 255 addresses because they will confuse people. It confused me even while writing this article, because I originally used a subnet mask of 255.255.255.240 as the example, but decided to "move it to the left" the make the point more plain. With that mask, 10.1.1.79 is the broadcast address for network 10.1.1.64, and my editing left that indication in.
Computers don't have problems with this, because they simply "and" the bits to determine what the network portion of an address is. The rules are easy for them, but we poor humans have to step more slowly.

The fine print There are some other rules, too. You aren't supposed to have a network composed of "all bits set", either. So all these would be "legal" networks when the mask is 255.255.240.0: 10.1.16.0, 10.1.32.0, 10.1.48.0, 10.1.64.0 10.1.80.0, 10.1.96.0, 10.1.112.0, 10.1.128.0 10.1.144.0, 10.1.160.0, 10.1.176.0, 10.1.192.0 10.1.208.0, 10.1.224.0 but 10.1.240.0 is not. For similar reasons, 10.1.0.0 is not legal for this subnet, either. So, for a subnet mask of 255.255.240.0, an address of less than 10.1.17.1 or greater than 10.1.239.254 is not legal. You should know, however, that there are plenty of functional networks that violate these rules. For example, I've seen the mask of 255.255.255.192
http://aplawrence.com/Unixart/advtcp.html Page 6 of 9

Advanced TCP/IP

9/1/11 11:34 AM

used. This actually only gives us 2 networks (10.1.1.64, and 10.1.1.128), but I've seen people uses addresses above 10.1.1.192 (which would be the "illegal" network of 10.1.1.192) and below 10.1.1.64 (which would be the other "wrong" network of 10.1.1.0). The networks work. If I understand recent changes correctly, these are now even "legal"; that is, subnets of all "0"'s or all "1"'s are now acceptable. This gets even more confusing when we get into classless routing (another article; hopefully for November 1998). Stranger stuff Interestingly (well, I think it's interesting, though you may be wishing you could smash all those network bits into little pieces and force-feed them to me), the RFC's on subnetting used to say that split netmasks are also legal. Thus, you could have a subnet mask of 10.1.1.129. This is a strange bit pattern:

By the rules we've learned, the bits set in the netmask determine the network. The network with none of the bits set is invalid, as is the network with both set. So for this netmask, we get just two networks, 10.1.1.128 and 10.1.1.1. The valid addresses for the 10.1.1.1 network are the odd addresses from 10.1.1.3 to 10.1.1.125, and for the 10.1.1.128 network, we use the even addresses from 10.1.1.130 to 10.1.1.252. It gets even more weird. The broadcast address on the 128 network is 10.1.1.254, but the broadcast on the 10.1.1.1 network would be 10.1.1.127. All other addresses (like 10.1.1.2 and 10.1.1.133) are "illegal". If this doesn't give you a headache, there is something very wrong with you! I have never seen split subnet masks actually used, and I can't imagine why anyone would want or need to. That's probably why they aren't "legal" anymore. What about that broadcast? I've mentioned broadcast addresses more than once, but haven't yet explained what that's all about. Painful as it is for both of us, it's time to do that.
http://aplawrence.com/Unixart/advtcp.html Page 7 of 9

Advanced TCP/IP

9/1/11 11:34 AM

The first thing you need to know is that these tcp/ip addresses don't mean anything, and are absolutely and completely unimportant, useless, and meaningless to a network card. Yes, you read that correctly: these addresses are not used by your network card at all. Never. Not in Unix, not in NT, not in your next door neighbor's shiny red convertible. Not used. Useless. Meaningless. This does not mean that tcp/ip addresses are useless to you: without some form of high level addressing we couldn't have routing, and the only way to break up networks into smaller junks would be bridging. But when it comes down to the real basics underneath, network cards do NOT use these addresses. Your network card, and mine, and even Bill Gates network card, only understands the MAC address that is burned into that card's on-board chips (not 100% true because the address can also be assigned by software, but it's still not a tcp/ip address). That address is a 6 octet number that might look like 00:04:05:54:17:d5 (hex numbers). When one network card wants to talk to another network card, they do so only by knowing each other's MAC addresses. So how do they get the address? By a broadcast, of course. A broadcast address is an address of all hex ff's (decimal 255's) that every card will listen to. The broadcast message asks a question: "who has this tcp/ip address 205.15.68.1?". All the cards on the network read that message, but only one (we hope) says "Yup, that's me?". But that still doesn't have anything to do with tcp/ip broadcast addresses. That was a MAC address broadcast. So what use is a tcp/ip broadcast? The full answer to that is another whole article on routers and bridges and switches and hubs, but the short answer is that the broadcast gets limited to a "broadcast domain". In other words, we expect the machines in a certain sub-net to be gathered together on one segment of a network. So when I said above that all the cards read the broadcast, I wasn't entirely telling the truth. All the cards that see it will read it, but broadcasts do not pass through routers. This means that the machines that belong to a particular sub-net only broadcast to each
http://aplawrence.com/Unixart/advtcp.html Page 8 of 9

Advanced TCP/IP

9/1/11 11:34 AM

other, thus limiting traffic to other sub-nets. So how does a machine on one sub-net get to talk to some other machine on a different sub-net, or perhaps (as may be happening as you read this) even half across the country or even the world? That, too, is a subject for another article. See also: Networking 101 Routing CIDR

If this page was useful to you, please click to help others find it:

Your +1's can help friends, contacts, and others on the web find the best stuff when they search.

More Articles by Tony Lawrence

http://aplawrence.com/Unixart/advtcp.html

Page 9 of 9