Networking with TCP/IP

08/23/2000

When you install FreeBSD, you are plunged into the wonderful world of
TCP/IP. You may have heard about DNS, ports, RFCs, private ranges, and
subnet masks but may be foggy on what these are and why you should
care. This article will be a primer on the TCP/IP protocol for the novice
and a refresher with some interesting links for those more seasoned
FreeBSD users.

First off, let's make sure you are clear on what a protocol is. By
definition, a protocol is the rules of communication. If you are
travelling in a foreign country, you need to be aware of the customs of
that country. A gesture that may seem friendly or insignificant to you may
actually be considered an insult in other parts of the world. Awareness of
protocol can save you the embarassment of miscommunication.

Protocols are even more important if two computers wish to exchange
information. Amazingly, computers communicate by subtly changing millions
of electrical pulses, light pulses, or radio waves per second. Both
computers need to be using the same protocol, or set of rules, to
correctly interpret which of these pulses represent the address of the
computer to receive the data, the address of the computer that sent the
data, the data itself, and confirmation that the data received was the
same data that was sent.

TCP/IP is more than a protocol; it is a protocol suite, or collection of
protocols. TCP/IP was designed to allow any operating system on any type
of hardware to talk to any other computer in the world. This is something
we take for granted in the age of the Internet, but before TCP/IP changed
all of the rules, operating systems, hardware, and protocols were
proprietary. Proprietary means that in order to exchange information with
another computer, it has to be running the same hardware and the same
version of the same operating system, which was provided by the vendor
of the hardware.

Because TCP/IP is a collection of protocols, new protocols can be added as
the capabilities of networking evolve. The designers of TCP/IP left room
for the creation of up to 65,535 application protocols. To keep track of
all of these application protocols (or rules for how an application
expects to receive data), each is assigned a number known as a port
number. For example, the port number for Telnet is 23 and the port number
for http is 80. If I wish to Telnet into a computer, TCP/IP will send out
packets that contain (among other information we'll ignore for the
moment) the port number 23. The other computer will realize that I wish to
use the rules for Telnet, which are very different than, say, the rules for
surfing or checking my e-mail.

Since TCP/IP is non-proprietary, anyone can add new functionality to
TCP/IP, pending a review process of their peers known as the RFC or
Request For Comments. RFCs were started before the actual development of
TCP/IP and have become a fascinating record of each step in the evolution
of TCP/IP and the Internet. Ever wonder about who invented DNS and why and all
the nitty-gritty details of how DNS actually works? The answer lies in the
associated RFCs, which are available for anyone to read via the Internet.

There are many good sites on the Internet where you can search for and
read RFCs. Two of these are:

The RFC Database - sometimes slow due to its popularity. If it is too slow, do a
Yahoo search for "rfc search" to find other RFC sites.

Perhaps you've been told that reading RFCs is as much fun as reading
manpages. Admittedly, RFCs can be written by anyone, so writing styles will
differ. Some good RFCs to start with are:

RFCs 1000, 1251, 2235, and 2468 - if you're interested in hearing about the history of the Internet from some of the people who made it happen

RFCs 968, 1121, and 1882 - just in case you thought computer geeks had no sense of humor. If you enjoy humorous RFCs, see this list.

Anyway, back to ports. Your FreeBSD system contains a database file of
port numbers and associated TCP/IP applications in /etc/services. If you need to know the port number for an application or vice-versa, a quick
grep of this file will reveal the information:

With these two commands, I've determined that the port number used by
ssh is 22 and that port 69 is used by the tftp application. Note that I used -w for the second grep; if you try the same command without the switch, grep will return all port numbers with a 69 in them.

Also note that each application has two port numbers: one for TCP and one
for UDP. TCP and UDP are known as transport protocols. While there are
thousands of TCP/IP applications, there are only two ways of
"transporting" an application's data between computers. UDP is the
connectionless transport, meaning that it just sends out data without
double-checking that the other computer is ready to receive the data. This
is similar to you just showing up at a friend's house in the hope that
he may be home. TCP is the connection-oriented transport; it will not
send out any data until it has contacted the other computer to ensure that
it is ready to receive data. This would be similar to you phoning your
friend first to see if he is home and willing to have you come over for a
visit.

Once TCP/IP has determined which application you wish to use and how that
application wishes to transport its data, it needs a mechanism to make
sure the data makes it to the right computer. In other words, it needs an
addressing scheme. The only type of address TCP/IP understands is an IP
address; if your computer does not have an IP address, you can't use
TCP/IP. Most operating systems use IPv4 (IP version 4) IP addresses, but
this will be changing within the next few years as the Internet is slowly
transitioned over to IPv6. If you are running FreeBSD 4.0 and above, your
system understands both versions of IP addresses.

In IPv4, an IP address is divided into two parts: one part indicates the
address of the network and the second part indicates the address of the
host. (In TCP/IP, anything with an IP address is called a host, or
sometimes a node.) All IPv4 addresses contain four numbers ranging from
0-255 separated by three periods; this is called dotted decimal
notation. Each number is the decimal equivalent of eight binary bits, so it
really represents an octet, or eight numbers. Which octets represent the
network and the host addresses depends upon the class of IP address, as
seen in the following table:

Class

Network ID

Host ID

Range

A

first octet

last three octets

1-126

B

first two octets

last two octets

128-191

C

first three octets

last octet

192-223

To determine the class of an IP address, compare the number in the first
octet to the Range column of the table. For example, 163.48.92.47 is a Class B address, since the 163 in the first octet falls within the range of 128-191. Because it is a Class B address, the first two octets, 163.48, represent the network address, and the last two octets, 92.47, represent the host address.

TCP/IP was designed to use a globally unique addressing scheme. This means
you can't just make up an IP address for your computer, because it may conflict
with an IP address that someone paid money to use. Network portions of an
IP address are purchased to guarantee they are unique; once you have a
network address, you can do whatever you want with the host addresses as
long as no two computers in your network have the same host address.

Fortunately, each class of IP address also has a reserved private
range. Anyone can use a private range network address for their own
network; the only caveat is that you'll need a real (or purchased) IP address
if you want to leave your network: for example, if you want to access the
Internet. The following table shows the private ranges:

Class

Private Range

A

10.x.x.x

B

172.16.x.x to 172.31.x.x

C

192.168.x.x

It is a good thing to use one of the private ranges on your network; which
class you use is up to you. Most networks use a combination of private
range IP addresses and NAT, or Network Address Translation. NAT is a
software mechanism that allows a network of private addresses (which can't
go on the Internet) to share a real IP address (which can go on the
Internet).

Every IPv4 address must also have a subnet mask. I won't get into subnet
masking in this article as that topic alone would fill a whole other
article. If you're curious about subnet masking, 3Com's article on
Everything You Ever Wanted to Know about IP addressing is a must-read.

However, you do need to be aware of the default subnet masks so you can
use the correct subnet mask for your IP address. The default subnet masks
are different for each class:

Class

Default Subnet Mask

A

255.0.0.0

B

255.255.0.0

C

255.255.255.0

In my test network, I have three computers. I've decided to use the
private Class A network range, the default subnet mask, and to use host
addressess of 1, 2, and 3. This translates into the following addresses:

Hostname

IP address

Subnet mask

alpha

10.0.0.1

255.0.0.0

beta

10.0.0.2

255.0.0.0

gamma

10.0.0.3

255.0.0.0

On the computer named alpha, I used the ifconfig utility to "bind" an IP address to its NIC. In order to do this, I first had to determine the device name of the NIC using the following command:

dmesg | grep Ethernetrl0: Ethernet address: 00:00:b4:94:9d:3f

which shows that the device name of alpha's NIC is rl0. To see if there is an IP address bound to your NIC, use the following command if you're
running FreeBSD 4.0 and above (but substitute your NIC's device name for
rl0):

Once you've bound an IP address to a NIC, you'll want to use the ping
utility to ensure that the NIC can send and receive TCP/IP packets.

ping 127.0.0.1

is called pinging your loopback address. This will check that TCP/IP has
been initialized on your system. If this test does not work, you can't use
TCP/IP.

ping 10.0.0.1

will check that your IP address is valid. If this test does not work,
check that you have a valid IP address and subnet mask and that no other
host is using the same IP address.

ping 10.0.0.2

If you have another host on your network, ping its IP address. If this
last test works, you're in business. If not, double-check your network
cabling and ensure that the other computer is turned on and that you are pinging
the correct address.

TCP/IP uses IP addresses, but humans like to use hostnames. Quick, what's
the IP address of www.yahoo.com? Don't feel bad if you don't know, as you
don't need to in order to access Yahoo's webpage. Hostname resolution was
designed to map hostnames to the IP addresses that TCP/IP understands. If
you have a small network, you can use the /etc/hosts file to provide hostname resolution. DNS databases provide the same function in larger
networks and on the Internet. DNS is far beyond the scope of this
article; if you need to setup a DNS server, I highly recommend that you first
read DNS and BIND by Cricket Liu and Paul Albitz. The DNS Resources Directory site also contains many useful documents on DNS.

However, editing the /etc/hosts file is an easy matter. First, you need to know, and possibly set, your hostname using the hostname utility. Anyone
can view the computer's hostname by typing hostname. Only root can change the computer's hostname. One way to change a computer's hostname is like so:

hostname alpha

This will set the computer's hostname to alpha.

Once the computers in your network have hostnames, you should edit the
/etc/hosts file so you can access resources by hostname instead of IP address. Again, only root can modify this file. Each of the computers in
my network has an /etc/hosts file that looks like this:

After you edit the /etc/hosts file, always try pinging the hostnames that you've added. For example:

ping alpha
ping beta
ping gamma

If any of the pings fail, you either have a typo in your etc/hosts file or the hostname has not been set on that computer.

Well, that's probably enough about TCP/IP for one day. We'll be revisiting
TCP/IP in future articles and will add more details to these basic
concepts as we go along. Next week, we'll explore the world of e-mail and
how your FreeBSD system uses two TCP/IP ports to allow you to exchange
e-mail messages with the world.

Dru Lavigne
is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.