Rutgers University - TCP/IP

A GUIDE TO TCP/IP INTERNETWORKING

Standard HTML 4.01 document

RFC Index: www.c-extra.com

Origin: Rutgers University

1 Introduction to the TCP/IP protocols

1.6 TCP/IP over point-to-point lines: SLIP and PPP

In the last few years, there has been an explosive growth in the number of hosts supporting TCP/IP. The vast majority of these hosts are connected to Local Area Networks (LANs) of various types, Ethernet being the most common. Most of the other hosts are connected through Wide Area Networks (WANs) such as X.25 style Public Data Networks (PDNs). Relatively few of these hosts are connected with simple point-to-point (i.e., serial) links. Yet, point-to-point links are among the oldest methods of data communications and almost every host supports point-to-point connections. For example, asynchronous RS-232C interfaces are essentially ubiquitous. One reason for the small number of point-to-point IP links is the lack of a standard encapsulation protocol. There are plenty of non-standard (and at least one defacto standard: SLIP) encapsulation protocols available, but there is not one which has been agreed upon as an TCP/IP Standard. By contrast, standard encapsulation schemes do exist for the transmission of datagrams over most popular LANs.

SLIP (Serial Line IP), has become a de facto standard, commonly used for point-to-point serial connections running TCP/IP, but it is not a TCP/IP standard. SLIP is merely a packet framing protocol: it defines a sequence of characters that frame IP packets on a serial line, and nothing more. It provides no addressing, packet type identification, error detection-correction or compression mechanisms. Because the protocol does so little, though, it is usually very easy to implement. SLIP is commonly used on dedicated serial links and sometimes for dialup purposes, and is usually used with line speeds between 1200 b/s and 19200 b/s or more. It is useful for allowing mixes of hosts and routers to communicate with one another (host-host, host-router and router-router are all common SLIP network configurations). SLIP is available for most Berkeley UNIX-based systems. It is included in the standard 4.3BSD release from Berkeley. SLIP is available for Ultrix, Sun UNIX and most other Berkeley-derived UNIX systems. Some terminal concentrators and IBM PC implementations as KA9Q and PC/TCP also support it. Because there is no 'standard' SLIP specification, there is no real defined maximum packet size for SLIP. It is probably best to accept the maximum packet size used by the Berkeley UNIX SLIP drivers: 1006 bytes including the IP and transport protocol headers (not including the framing characters). Therefore any new SLIP implementations should be prepared to accept 1006 byte datagrams and should not send more than 1006 bytes in a datagram.

The Point-to-Point Protocol (PPP) is a new TCP/IP protocol that is a standard and remedies SLIP deficiencies. PPP provides a method for transmitting datagrams over serial point-to-point links. It is composed of three parts:

1) A method for encapsulating datagrams over serial links. The PPP encapsulation provides for multiplexing of different network-layer protocols simultaneously over the same link. It is intended that PPP provide a common solution for easy connection of a wide variety of hosts, bridges and routers. PPP uses HDLC as a basis for encapsulating datagrams over point-to-point links. At this time, PPP specifies the use of asynchronous or synchronous duplex circuits, either dedicated or circuit switched.

2) An extensible Link Control Protocol (LCP). The Link Control Protocol (LCP) provides a method of establishing, configuring, maintaining and terminating the point-to-point connection. LCP goes through four distinct phases:
Phase 1: Link Establishment and Configuration Negotiation
Phase 2: Link Quality Determination
Phase 3: Network-Layer Protocol Configuration Negotiation
Phase 4: Link Termination

3) A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network-layer protocols.

Point-to-point links tend to exacerbate many problems with the current family of network protocols. For instance, assignment and management of IP addresses, which is a problem even in LAN environments, is especially difficult over circuit switched point-to-point circuits (e.g., dialups). Some additional issues addressed by this specification of PPP include asynchronous (start/stop) and bit-oriented synchronous encapsulation, network protocol multiplexing, link configuration, link quality testing, error detection, and option negotiation for such capabilities as network-layer address negotiation and data compression negotiation. PPP addresses these issues by providing an extensible LCP and a family of NCP to negotiate optional configuration parameters and facilities. In order to establish communications over a point-to-point link, the originating PPP would first send LCP packets to configure and test the data link. After the link has been establish and optional facilities have been negotiated as needed by the LCP, the originating PPP would send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (e.g., inactivity timer expires or user intervention). The Point-to-Point Protocol is capable of operating across any DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and CCITT V.35). The only absolute requirement imposed by PPP is the provision of a duplex circuit, either dedicated or circuit switched, which can operate in either an asynchronous (start/stop) or synchronous bit-serial mode, transparent to PPP Data Link Layer frames. PPP does not impose any restrictions regarding transmission rate, other than those imposed by the particular DTE/DCE interface in use. PPP does not require the use of modem control signals, such as Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and Data Terminal Ready (DTR). However, using such signals when available can allow greater functionality and performance. At the Data Link Layer, the Point-to-Point Protocol uses the principles, terminology, and frame structure of the International Organization For Standardization's (ISO) High-level Data Link Control (HDLC) procedures. A summary of the standard PPP frame structure is shown below. The fields are transmitted from left to right.

+----------+----------+----------+----------+---//--+----------+----------+ |   Flag   | Address  | Control  | Protocol | Data  |   FCS    |   Flag   | | 01111110 | 11111111 | 00000011 |  16 bits |       | 16 bits  | 01111110 | +----------+----------+----------+----------+---//--+----------+----------+

This figure does not include start/stop bits (for asynchronous links) or any bits or octets inserted for transparency. When asynchronous links are used, all octets are transmitted with one start bit, eight bits of data, and one stop bit. The Address field is a single octet and contains the binary sequence 11111111 (hexadecimal 0xff), the All-Stations address. PPP does not assign individual station addresses. The All-Stations address should always be recognized and received. It is intended that PPP links be easy to configure. By design, the standard defaults handle all common configurations. The implementor can specify improvements to the default configuration, which are automatically communicated to the peer without operator intervention. Finally, the operator may explicitly configure options for the link which enable the link to operate in environments where it would otherwise be impossible. This self-configuration is implemented through an extensible option negotiation mechanism, wherein each end of the link describes to the other its capabilities and requirements. Although the option negotiation mechanism described in this document is specified in terms of LCP, the same facilities are designed to be used by other control protocols, especially the family of NCPs.

1.7 Well-known sockets and the applications layer

So far, we have described how a stream of data is broken up into datagrams, sent to another computer, and put back together. However something more is needed in order to accomplish anything useful. There has to be a way for you to open a connection to a specified computer, log into it, tell it what file you want, and control the transmission of the file. (If you have a different application in mind, e.g. computer mail, some analogous protocol is needed). This is done by "application protocols". The application protocols run "on top" of TCP/IP. That is, when they want to send a message, they give the message to TCP. TCP makes sure it gets delivered to the other end. Because TCP and IP take care of all the networking details, the applications protocols can treat a network connection as if it were a simple byte stream, like a terminal or phone line. Before going into more details about applications programs, we have to describe how you find an application. Suppose you want to send a file to a computer whose Internet address is 128.6.4.7. To start the process, you need more than just the Internet address. You have to connect to the FTP server at the other end. In general, network programs are specialized for a specific set of tasks. Most systems have separate programs to handle file transfers, remote terminal logins, mail, etc. When you connect to 128.6.4.7, you have to specify that you want to talk to the FTP server. This is done by having "well-known sockets" for each server. Recall that TCP uses port numbers to keep track of individual conversations. User programs normally use more or less random port numbers. However specific port numbers are assigned to the programs that sit waiting for requests. For example, if you want to send a file, you will start a program called "ftp". It will open a connection using some random number, say 1234, for the port number on its end. However it will specify port number 21 for the other end. This is the official port number for the FTP server. Note that there are two different programs involved. You run ftp on your side. This is a program designed to accept commands from your terminal and pass them on to the other end. The program that you talk to on the other machine is the FTP server. It is designed to accept commands from the network connection, rather than an interactive terminal. There is no need for your program to use a well-known socket number for itself. Nobody is trying to find it. However the servers have to have well-known numbers, so that people can open connections to them and start sending them commands. The official port numbers for each program are given in "Assigned Numbers". Note that a connection is actually described by a set of 4 numbers: the Internet address at each end, and the TCP port number at each end. Every datagram has all four of those numbers in it. (The Internet addresses are in the IP header, and the TCP port numbers are in the TCP header). In order to keep things straight, no two connections can have the same set of numbers. However it is enough for any one number to be different. For example, it is perfectly possible for two different users on a machine to be sending files to the same other machine. This could result in connections with the following parameters:

                 Internet addresses:          TCP ports:                ----------------------        ------------ connection 1   128.6.4.194, 128.6.4.7        1234, 21 connection 2   128.6.4.194, 128.6.4.7        1235, 21

Since the same machines are involved, the Internet addresses are the same. Since they are both doing file transfers, one end of the connection involves the well-known port number for FTP. The only thing that differs is the port number for the program that the users are running. That's enough of a difference. Generally, at least one end of the connection asks the network software to assign it a port number that is guaranteed to be unique. Normally, it's the user's end, since the server has to use a well-known number. Now that we know how to open connections, let's get back to the applications programs. As mentioned earlier, once TCP has opened a connection, we have something that might as well be a simple wire. All the hard parts are handled by TCP and IP. However we still need some agreement as to what we send over this connection. In effect this is simply an agreement on what set of commands the application will understand, and the format in which they are to be sent. Generally, what is sent is a combination of commands and data. They use context to differentiate. For example, the mail protocol works like this: Your mail program opens a connection to the mail server at the other end. Your program gives it your machine's name, the sender of the message, and the recipients you want it sent to. It then sends a command saying that it is starting the message. At that point, the other end stops treating what it sees as commands, and starts accepting the message. Your end then starts sending the text of the message. At the end of the message, a special mark is sent (a dot in the first column). After that, both ends understand that your program is again sending commands. This is the simplest way to do things, and the one that most applications use. File transfer is somewhat more complex. The file transfer protocol involves two different connections. It starts out just like mail. The user's program sends commands like "log me in as this user", "here is my password", "send me the file with this name". However once the command to send data is sent, a second connection is opened for the data itself. It would certainly be possible to send the data on the same connection, as mail does. However file transfers often take a long time. The designers of the file transfer protocol wanted to allow the user to continue issuing commands while the transfer is going on. For example, the user might make an inquiry, or he might abort the transfer. Thus the designers felt it was best to use a separate connection for the data and leave the original command connection for commands. (It is also possible to open command connections to two different computers, and tell them to send a file from one to the other. In that case, the data couldn't go over the command connection). Remote terminal connections use another mechanism still. For remote logins, there is just one connection. It normally sends data. When it is necessary to send a command (e.g. to set the terminal type or to change some mode), a special character is used to indicate that the next character is a command. If the user happens to type that special character as data, two of them are sent. We are not going to describe the application protocols in detail in this document. It's better to read the RFC's yourself. However there are a couple of common conventions used by applications that will be described here. First, the common network representation: TCP/IP is intended to be usable on any computer. Unfortunately, not all computers agree on how data is represented. There are differences in character codes (ASCII vs. EBCDIC), in end of line conventions (carriage return, line feed, or a representation using counts), and in whether terminals expect characters to be sent individually or a line at a time. In order to allow computers of different kinds to communicate, each applications protocol defines a standard representation. Note that TCP and IP do not care about the representation. TCP simply sends octets. However the programs at both ends have to agree on how the octets are to be interpreted. The RFC for each application specifies the standard representation for that application. Normally it is "net ASCII". This uses ASCII characters, with end of line denoted by a carriage return followed by a line feed. For remote login, there is also a definition of a "standard terminal", which turns out to be a half-duplex terminal with echoing happening on the local machine. Most applications also make provisions for the two computers to agree on other representations that they may find more convenient. For example, PDP-10's have 36-bit words. There is a way that two PDP-10's can agree to send a 36-bit binary file. Similarly, two systems that prefer full-duplex terminal conversations can agree on that. However each application has a standard representation, which every machine must support.

1.8 Protocols other than TCP: UDP and ICMP

So far, we have described only connections that use TCP. Recall that TCP is responsible for breaking up messages into datagrams, and reassembling them properly. However in many applications, we have messages that will always fit in a single datagram. An example is name lookup. When a user attempts to make a connection to another system, he will generally specify the system by name, rather than Internet address. His system has to translate that name to an address before it can do anything. Generally, only a few systems have the database used to translate names to addresses. So the user's system will want to send a query to one of the systems that has the database. This query is going to be very short. It will certainly fit in one datagram. So will the answer. Thus it seems silly to use TCP. Of course TCP does more than just break things up into datagrams. It also makes sure that the data arrives, resending datagrams where necessary. But for a question that fits in a single datagram, we don't need all the complexity of TCP to do this. If we don't get an answer after a few seconds, we can just ask again. For applications like this, there are alternatives to TCP. The most common alternative is UDP (user datagram protocol). UDP is designed for applications where you don't need to put sequences of datagrams together. It fits into the system much like TCP. There is a UDP header. The network software puts the UDP header on the front of your data, just as it would put a TCP header on the front of your data. Then UDP sends the data to IP, which adds the IP header, putting UDP's protocol number in the protocol field instead of TCP's protocol number. However UDP doesn't do as much as TCP does. It doesn't split data into multiple datagrams. It doesn't keep track of what it has sent so it can resend if necessary. About all that UDP provides is port numbers, so that several programs can use UDP at once. UDP port numbers are used just like TCP port numbers. There are well-known port numbers for servers that use UDP. Note that the UDP header is shorter than a TCP header. It still has source and destination port numbers, and a checksum, but that's about it. No sequence number, since it is not needed. UDP is used by the protocols that handle name lookups (see IEN 116, RFC 882, and RFC 883), and number of similar protocols. This is the format of an UDP datagram:

          0                                 31          +--------+--------+--------+--------+          |     Source      |   Destination   |          |      Port       |      Port       |          +--------+--------+--------+--------+          |                 |                 |          |     Length      |    Checksum     |          +--------+--------+--------+--------+          |          |          data octets ...          +---------------- ...

Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted. Destination Port has a meaning within the context of a particular internet destination address. Length is the length in octets of this user datagram including this header and the data. (This means the minimum value of the length is eight). Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. A pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This information gives protection against misrouted datagrams. This checksum procedure is the same as is used in TCP. If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care).

Another alternative protocol is ICMP (Internet control message protocol). ICMP is used for error messages, and other messages intended for the TCP/IP software itself, rather than any particular user program. For example, if you attempt to connect to a host, your system may get back an ICMP message saying "host unreachable". ICMP can also be used to find out some information about the network. See RFC 792 for details of ICMP. ICMP is similar to UDP, in that it handles messages that fit in one datagram. However it is even simpler than UDP. It doesn't even have port numbers in its header. Since all ICMP messages are interpreted by the network software itself, no port numbers are needed to say where a ICMP message is supposed to go.

ICMP uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP, and must be implemented by every IP module. ICMP messages are sent in several situations: for example, when a datagram cannot reach its destination, when the gateway does not have the buffering capacity to forward a datagram, and when the gateway can direct the host to send traffic on a shorter route. The Internet Protocol is not designed to be absolutely reliable. The purpose of these control messages is to provide feedback about problems in the communication environment, not to make IP reliable. There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams may still be undelivered without any report of their loss. The higher level protocols that use IP must implement their own reliability procedures if reliable communication is required. The ICMP messages typically report errors in the processing of datagrams. To avoid the infinite regress of messages about messages etc., no ICMP messages are sent about ICMP messages. Also ICMP messages are only sent about errors in handling fragment zero of fragmented datagrams. (Fragment zero has the fragment offset equal zero). ICMP messages are sent using the basic IP header. The first octet of the data portion of the datagram is a ICMP type field; the value of this field determines the format of the remaining data. Any field labeled "unused" is reserved for later extensions and must be zero when sent, but receivers should not use these fields (except to include them in the checksum). Here are 2 examples of ICMP messages:

Destination Unreachable Message:

0                   1                   2                   3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |     Type      |     Code      |          Checksum             | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                             Unused                            | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |      Internet Header + 64 bits of Original Data Datagram      | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 3
Code: 0 = net unreachable; 1 = host unreachable; 2 = protocol unreachable; 3 = port unreachable; 4 = fragmentation needed and DF set; 5 = source route failed.

Echo or Echo Reply Message:

0                   1                   2                   3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |     Type      |     Code      |          Checksum             | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |           Identifier          |        Sequence Number        | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |     Data ... +-+-+-+-+-

Type: 8 for echo message; 0 for echo reply message.
Code: 0
Identifier: If code = 0, an identifier to aid in matching echos and replies, may be zero.
Sequence Number: If code = 0, a sequence number to aid in matching echos and replies, may be zero.

1.9 The domain name system (DNS)

As we indicated earlier, the network software generally needs a 32-bit Internet address in order to open a connection or send a datagram. However users prefer to deal with computer names rather than numbers. Thus there is a database that allows the software to look up a name and find the corresponding number. When the Internet was small, this was easy. Each system would have a file that listed all of the other systems, giving both their name and number. There are now too many computers for this approach to be practical. Thus these files have been replaced by a set of name servers that keep track of host names and the corresponding Internet addresses. (In fact these servers are somewhat more general than that. This is just one kind of information stored in the domain system). Note that a set of interlocking servers are used, rather than a single central one. There are now so many different institutions connected to the Internet that it would be impractical for them to notify a central authority whenever they installed or moved a computer. Thus naming authority is delegated to individual institutions. The name servers form a tree, corresponding to institutional structure. The names themselves follow a similar structure. A typical example is the name BORAX.LCS.MIT.EDU. This is a computer at the Laboratory for Computer Science (LCS) at MIT. In order to find its Internet address, you might potentially have to consult 4 different servers. First, you would ask a central server (called the root) where the EDU server is. EDU is a server that keeps track of educational institutions. The root server would give you the names and Internet addresses of several servers for EDU. (There are several servers at each level, to allow for the possibly that one might be down). You would then ask EDU where the server for MIT is. Again, it would give you names and Internet addresses of several servers for MIT. Generally, not all of those servers would be at MIT, to allow for the possibility of a general power failure at MIT. Then you would ask MIT where the server for LCS is, and finally you would ask one of the LCS servers about BORAX. The final result would be the Internet address for BORAX.LCS.MIT.EDU. Each of these levels is referred to as a "domain". The entire name, BORAX.LCS.MIT.EDU, is called a "domain name". (So are the names of the higher-level domains, such as LCS.MIT.EDU, MIT.EDU, and EDU). Fortunately, you don't really have to go through all of this most of the time. First of all, the root name servers also happen to be the name servers for the top-level domains such as EDU. Thus a single query to a root server will get you to MIT. Second, software generally remembers answers that it got before. So once we look up a name at LCS.MIT.EDU, our software remembers where to find servers for LCS.MIT.EDU, MIT.EDU, and EDU. It also remembers the translation of BORAX.LCS.MIT.EDU. Each of these pieces of information has a "time to live" associated with it. Typically this is a few days. After that, the information expires and has to be looked up again. This allows institutions to change things. The domain system is not limited to finding out Internet addresses. Each domain name is a node in a database. The node can have records that define a number of different properties. Examples are Internet address, computer type, and a list of services provided by a computer. A program can ask for a specific piece of information, or all information about a given name. It is possible for a node in the database to be marked as an "alias" (or nickname) for another node. It is also possible to use the domain system to store information about users, mailing lists, or other objects. There is an Internet standard defining the operation of these databases, as well as the protocols used to make queries of them. Every network utility has to be able to make such queries, since this is now the official way to evaluate host names. Generally utilities will talk to a server on their own system. This server will take care of contacting the other servers for them. This keeps down the amount of code that has to be in each application program. The domain system is particularly important for handling computer mail. There are entry types to define what computer handles mail for a given name, to specify where an individual is to receive mail, and to define mailing lists. (See RFC's 882, 883, and 973 for specifications of the domain system. RFC 974 defines the use of the domain system in sending mail).

1.10 An example of network application: SMTP

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. An important feature of SMTP is its capability to relay mail across transport service environments. The SMTP design is based on the following model of communication: as the result of a user mail request, the sender-SMTP establishes a two-way transmission channel to a receiver-SMTP. The receiver-SMTP may be either the ultimate destination or an intermediate. SMTP commands are generated by the sender-SMTP and sent to the receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the sender-SMTP in response to the commands. Once the transmission channel is established, the SMTP-sender sends a MAIL command indicating the sender of the mail. If the SMTP-receiver can accept mail it responds with an OK reply. The SMTP-sender then sends a RCPT command identifying a recipient of the mail. If the SMTP-receiver can accept mail for that recipient it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but not the whole mail transaction). The SMTP-sender and SMTP-receiver may negotiate several recipients. When the recipients have been negotiated the SMTP-sender sends the mail data, terminating with a special sequence. If the SMTP-receiver successfully processes the mail data it responds with an OK reply. The dialog is purposely lock-step, one-at-a-time. The SMTP provides mechanisms for the transmission of mail; directly from the sending user's host to the receiving user's host when the two host are connected to the same transport service, or via one or more relay SMTP-servers when the source and destination hosts are not connected to the same transport service. To be able to provide the relay capability the SMTP-server must be supplied with the name of the ultimate destination host as well as the destination mailbox name.

ºIn order to give a bit better idea what is involved in SMTP, I'm going to show an example. We assume that a computer called TOPAZ.RUTGERS.EDU wants to send the following message:

Date: Mon, 27 Jun 95 13:26:31 EDT
From: hedrick@topaz.rutgers.edu
To: levy@red.rutgers.edu
Subject: meeting
Let's get together Monday at 1pm.

First, note that the format of the message itself is described by an Internet standard (RFC 822). The standard specifies the fact that the message must be transmitted as net ASCII (i.e. it must be ASCII, with carriage return/linefeed to delimit lines). It also describes the general structure, as a group of header lines, then a blank line, and then the body of the message. Finally, it describes the syntax of the header lines in detail. Generally they consist of a keyword and then a value. Note that the addressee is indicated as LEVY@RED.RUTGERS.EDU, which is the domain-name system. Initially, addresses were simply "person at machine". However recent standards have made things more flexible. There are now provisions for systems to handle other systems' mail. This can allow automatic forwarding on behalf of computers not connected to the Internet. It can be used to direct mail for a number of systems to one central mail server. Indeed there is no requirement that an actual computer by the name of RED.RUTGERS.EDU even exist. The name servers could be set up so that you mail to department names, and each department's mail is routed automatically to an appropriate computer. It is also possible that the part before the @ is something other than a user name. It is possible for programs to be set up to process mail. There are also provisions to handle mailing lists, and generic names such as "postmaster" or "operator". The way the message is to be sent to another system is described by RFC's 821 and 974. The program that is going to be doing the sending asks the name server several queries to determine where to route the message. The first query is to find out which machines handle mail for the name RED.RUTGERS.EDU. In this case, the server replies that RED.RUTGERS.EDU handles its own mail. The program then asks for the address of RED.RUTGERS.EDU, which is 128.6.4.2. Then the mail program opens a TCP connection to port 25 on 128.6.4.2. Port 25 is the well-known socket used for receiving mail. Once this connection is established, the mail program starts sending commands. Here is a typical conversation. Each line is labelled as to whether it is from TOPAZ or RED. Note that TOPAZ initiated the connection:

RED 220 RED.RUTGERS.EDU SMTP Service at 29 Jun 95 05:17:18 EDT
TOPAZ HELO topaz.rutgers.edu
RED 250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU
TOPAZ MAIL From:<hedrick@topaz.rutgers.edu>
RED 250 MAIL accepted
TOPAZ RCPT To:<levy@red.rutgers.edu>
RED 250 Recipient accepted
TOPAZ DATA
RED 354 Start mail input; end with <CRLF>.<CRLF>
TOPAZ Date: Sat, 27 Jun 95 13:26:31 EDT
TOPAZ From: hedrick@topaz.rutgers.edu
TOPAZ To: levy@red.rutgers.edu
TOPAZ Subject: meeting
TOPAZ
TOPAZ Let's get together Monday at 1pm.
TOPAZ .
RED 250 OK
TOPAZ QUIT
RED 221 RED.RUTGERS.EDU Service closing transmission channel

First, note that commands all use normal text. This is typical of the Internet standards. Many of the protocols use standard ASCII commands. This makes it easy to watch what is going on and to diagnose problems. For example, the mail program keeps a log of each conversation. If something goes wrong, the log file can simply be mailed to the postmaster. Since it is normal text, he can see what was going on. It also allows a human to interact directly with the mail server, for testing. (Some newer protocols are complex enough that this is not practical. The commands would have to have a syntax that would require a significant parser. Thus there is a tendency for newer protocols to use binary formats. Generally they are structured like C or Pascal record structures). Second, note that the responses all begin with numbers. This is also typical of Internet protocols. The allowable responses are defined in the protocol. The numbers allow the user program to respond unambiguously. The rest of the response is text, which is normally for use by any human who may be watching or looking at a log. It has no effect on the operation of the programs. (However there is one point at which the protocol uses part of the text of the response). The commands themselves simply allow the mail program on one end to tell the mail server the information it needs to know in order to deliver the message. In this case, the mail server could get the information by looking at the message itself. But for more complex cases, that would not be safe. Every session must begin with a HELO, which gives the name of the system that initiated the connection. Then the sender and recipients are specified. (There can be more than one RCPT command, if there are several recipients). Finally the data itself is sent. Note that the text of the message is terminated by a line containing just a period. (If such a line appears in the message, the period is doubled). After the message is accepted, the sender can send another message, or terminate the session as in the example above. Generally, there is a pattern to the response numbers. The protocol defines the specific set of responses that can be sent as answers to any given command. However programs that don't want to analyze them in detail can just look at the first digit. In general, responses that begin with a 2 indicate success. Those that begin with 3 indicate that some further action is needed, as shown above. 4 and 5 indicate errors. 4 is a "temporary" error, such as a disk filling. The message should be saved, and tried again later. 5 is a permanent error, such as a non-existent recipient. The message should be returned to the sender with an error message. (For more details about the protocols mentioned in this section, see RFC's 821/822 for mail, RFC 959 for file transfer, and RFC's 854/855 for remote logins. For the well-known port numbers, see the current edition of Assigned Numbers, and possibly RFC 814).

2. Addressing and routing

2.1 The problem

This part is particularly intended to help people who are planning to set up a new network based on TCP/IP, or to administer an existing one. It is directed at networks of "medium" complexity. That is, it is probably appropriate for a network involving several dozen buildings. Those planning to manage larger networks will need more preparation than you can get by reading this document.

We are going to use the term "IP" to refer to networks designed to carry TCP/IP. IP is the network-level protocol from the Internet (TCP/IP) family of protocols. Thus it is common practice to use the term "IP" when referring to addresses, routing, and other network-layer items. In fact the distinction is not always very clear. So in practice the terms Internet, TCP/IP, and IP may appear to be almost interchangeable. The terms "packet" and "datagram" are also almost interchangeable. Ideally, "packet" is used for the lowest-level physical unit, whereas "datagram" refers to a unit of data at the level of IP. However these are identical for most media, so people have nearly stopped making the distinction. The term "packet" seems to be winning out in common speech. For example, router speeds are generally given in "packets per second." We use the term "router" even if "gateway" is the original Internet term.

When we described TCP/IP protocols above, it was indicated that the IP implementation is responsible for getting datagrams to the destination indicated by the destination address, but little was said about how this would be done. The task of finding how to get a datagram to its destination is referred to as "routing". In fact many of the details depend upon the particular implementation. However some general things can be said. First, it is necessary to understand the model on which IP is based. IP assumes that a system is attached to some local network. We assume that the system can send datagrams to any other system on its own network. (In the case of Ethernet, it simply finds the Ethernet address of the destination system, and puts the datagram out on the Ethernet). The problem comes when a system is asked to send a datagram to a system on a different network. This problem is handled by IP routers. A router (also known as a gateway) is a device that connects a network with one or more other networks. Routers are sometimes just normal computers that happen to have more than one network interface. For example, we can have a UNIX machine that has two different Ethernet interfaces, connected to networks 128.6.4 and 128.6.3. This machine can act as a router between those two networks. The software on that machine must be set up so that it will forward datagrams from one network to the other. That is, if a machine on network 128.6.4 sends a datagram to the router, and the datagram is addressed to a machine on network 128.6.3, the router will forward the datagram to the destination. Major communications centers often have routers that connect a number of different networks. In many cases, special-purpose router (such as those manufactured by Cisco, 3Com, Wellfleet, etc.) provide better performance or reliability than general-purpose computers acting as routers. Routing in IP is based entirely upon the network number of the destination address. Each computer has a table of network numbers. For each network number, a router is listed. This is the router to be used to get to that network. Note that the router doesn't have to connect directly to the network. It just has to be the best place to go to get there. For example at Rutgers University, the interface to NSFnet is at the John von Neuman Supercomputer Center (JvNC). Connection to JvNC is via a high-speed serial line connected to a router whose address is 128.6.3.12. Systems on net 128.6.3 will list 128.6.3.12 as the router for many off-campus networks. However systems on net 128.6.4 will list 128.6.4.1 as the router to those same off-campus networks. 128.6.4.1 is the router between networks 128.6.4 and 128.6.3, so it is the first step in getting to JvNC. When a computer wants to send a datagram, it first checks to see if the destination address is on the system's own local network. If so, the datagram can be sent directly. Otherwise, the system expects to find an entry for the network that the destination address is on. The datagram is sent to the router listed in that entry. This table can get quite big. For example, the Internet now includes millions of individual networks. Thus various strategies have been developed to reduce the size of the routing table. One strategy is to depend upon "default routes". Often, there is only one router out of a network. This router might connect a local Ethernet to a campus-wide backbone network. In that case, we don't need to have a separate entry for every network in the world. We simply define that router as a "default". When no specific route is found for a datagram, the datagram is sent to the default router. A default router can even be used when there are several routers on a network. There are provisions for routers to send a message saying "I'm not the best router: use this one instead". (The message is sent via ICMP, see RFC 792). Most network software is designed to use these messages to add entries to their routing tables.

Suppose network 128.6.4 has two routers, 128.6.4.59 and 128.6.4.1. Router 128.6.4.59 leads to several other internal Rutgers networks. Router 128.6.4.1 leads indirectly to the NSFnet. Suppose we set 128.6.4.59 as a default router, and have no other routing table entries. Now what happens when we need to send a datagram to MIT, which is network 18 ? Since we have no entry for network 18, the datagram will be sent to the default, 128.6.4.59. As it happens, this router is the wrong one. So it will forward the datagram to 128.6.4.1. But it will also send back an error saying in effect: "to get to network 18, use 128.6.4.1". Our software will then add an entry to the routing table. Any future datagrams to MIT will then go directly to 128.6.4.1. (The error message is sent using the ICMP protocol. The message type is called "ICMP redirect"). Most IP experts recommend that individual computers should not try to keep track of the entire network. Instead, they should start with default routers, and let the routers tell them the routes, as just described. However this doesn't say how the routers should find out about the routes. The routers can't depend upon this strategy. They have to have fairly complete routing tables. For this, some sort of routing protocol is needed. A routing protocol is simply a technique for the routers to find each other, and keep up to date about the best way to get to every network. RFC 1009 contains a review of router design and routing.

2.2 Details about IP addresses: subnets and broadcasting

As indicated earlier, Internet addresses are 32-bit numbers, normally written as 4 octets (in decimal), e.g. 128.6.4.7. There are actually 3 different types of address. The problem is that the address has to indicate both the network and the host within the network. It was felt that eventually there would be lots of networks. Many of them would be small, but probably 24 bits would be needed to represent all the IP networks. It was also felt that some very big networks might need 24 bits to represent all of their hosts. This would seem to lead to 48 bit addresses. But the designers really wanted to use 32 bit addresses. So they adopted a kludge. The assumption is that most of the networks will be small. So they set up three different ranges of address. Addresses beginning with 1 to 126 use only the first octet for the network number. The other three octets are available for the host number. Thus 24 bits are available for hosts. These numbers are used for large networks. But there can only be 126 of these very big networks. The Arpanet is one, and there are a few large commercial networks. But few normal organizations get one of these "class A" addresses. For normal large organizations, "class B" addresses are used. Class B addresses use the first two octets for the network number. Thus network numbers are 128.1 through 191.254. (We avoid 0 and 255, for reasons that we see below. We also avoid addresses beginning with 127, because that is used by some systems for special purposes). The last two octets are available for host addesses, giving 16 bits of host address. This allows for 64516 computers, which should be enough for most organizations. (It is possible to get more than one class B address, if you run out). Finally, class C addresses use three octets, in the range 192.1.1 to 223.254.254. These allow only 254 hosts on each network, but there can be lots of these networks. Addresses above 223 are reserved for future use, as class D and E. Many large organizations find it convenient to divide their network number into "subnets". For example, Rutgers has been assigned a class B address, 128.6. It is then convenient to use the third octet of the address to indicate which Ethernet a host is on. This division has no significance outside of Rutgers. A computer at another institution would treat all datagrams addressed to 128.6 the same way. They would not look at the third octet of the address. Thus computers outside Rutgers would not have different routes for 128.6.4 or 128.6.5. But inside Rutgers, 128.6.4 and 128.6.5 are traeted as separate networks. In effect, routers inside Rutgers have separate entries for each Rutgers subnet, whereas routers outside Rutgers just have one entry for 128.6. Note that we could do exactly the same thing by using a separate class C address for each Ethernet. As far as Rutgers is concerned, it would be just as convenient have a number of class C addresses. However using class C addresses would make things inconvenient for the rest of the world. Every institution that wanted to talk to Rutgers would have to have a separate entry for each one of our networks. If every institution did this, there would be far too many networks for any reasonable router to keep track of. By subdividing a class B network, we hide the internal structure from everyone else, and save them trouble. This subnet strategy requires special provisions in the network software. It is described in RFC 950. 0 and 255 have special meanings. 0 is reserved for machines that don't know their address. In certain circumstances it is possible for a machine not to know the number of the network it is on, or even its own host address. For example, 0.0.0.23 would be a machine that knew it was host number 23, but didn't know on what network. 255 is used for "broadcast".

A broadcast is a message that you want every system on the network to see. Broadcasts are used in some situations where you don't know who to talk to. For example, suppose you need to look up a host name and get its Internet address. Sometimes you don't know the address of the nearest name server. In that case, you might send the request as a broadcast. There are also cases where a number of systems are interested in information. It is then less expensive to send a single broadcast than to send datagrams individually to each host that is interested in the information. In order to send a broadcast, you use an address that is made by using your network address, with all ones in the part of the address where the host number goes. For example, if you are on network 128.6.4, you would use 128.6.4.255 for broadcasts. How this is actually implemented depends upon the medium. It is not possible to send broadcasts on the Internet, or on point to point lines. However it is possible on an Ethernet. If you use an Ethernet address with all its bits on (all ones), every machine on the Ethernet is supposed to look at that datagram. Although the official broadcast address for network 128.6.4 is now 128.6.4.255, there are some other addresses that may be treated as broadcasts by certain implementations. For convenience, the standard also allows 255.255.255.255 to be used. This refers to all hosts on the local network. It is often simpler to use 255.255.255.255 instead of finding out the network number for the local network and forming a broadcast address such as 128.6.4.255. In addition, certain older implementations may use 0 instead of 255 to form the broadcast address. Such implementations would use 128.6.4.0 instead of 128.6.4.255 as the broadcast address on network 128.6.4. Finally, certain older implementations may not understand about subnets. Thus they consider the network number to be 128.6. In that case, they will assume a broadcast address of 128.6.255.255 or 128.6.0.0. Until support for broadcasts is implemented properly, it can be a somewhat dangerous feature to use. Because 0 and 255 are used for unknown and broadcast addresses, normal hosts should never be given addresses containing 0 or 255. Addresses should never begin with 0, 127, or any number above 223.

2.3 Details about routing and addressing

Many of the decisions that you need to make in setting up an IP network depend upon routing, so it will be best to give a bit of background on that topic now. We will return to routing in a later section when discussing routers and bridges. In general, IP datagrams pass through many networks as they are going between the source and destination. Here's a typical example. (Addresses used in the examples are taken from Rutgers University):

       network 1                          network 2            network 3        128.6.4                            128.6.21             128.121       ===============================    =================    ==================         |            |            |        |           |        |            | ________|____  ______|______  ____|________|____   ____|________|____    ____|________   128.6.4.2      128.6.4.3        128.6.4.1            128.6.21.1        128.121.50.2                                  128.6.21.2           128.121.50.1 _____________  _____________  __________________   __________________    _____________ computer A     computer B        router R             router S           computer C

This diagram shows three normal computer systems, two routers, and three networks. The networks might be Ethernet, token ring, or any other sort. Network 2 could even be a single point to point line connecting routers R and S. Note that computer A can send datagrams to computer B directly, using network 1. However it can't reach computer C directly, since they aren't on the same network. There are several ways to connect separate networks. This diagram assumes that routers are used. (In a later section, we'll look at alternatives). In this case, datagrams going between A and C must be sent through router R, network 2, and router S. Every computer that uses TCP/IP needs appropriate information and algorithms to allow it to know when datagrams must be sent through a router, and to choose an appropriate router. Routing is very closely tied to the choice of addresses. Note that the address of each computer begins with the number of the network that it's attached to. Thus 128.6.4.2 and 128.6.4.3 are both on network 128.6.4. Next, notice that routers, whose job is to connect networks, have an address on each of those networks. For example, router R connects networks 128.6.4 and 128.6.21. Its connection to network 128.6.4 has the address 128.6.4.1. Its connection to network 128.6.21 has the address 128.6.21.2. Because of this association between addresses and networks, routing decisions can be based strictly on the network number of the destination. Here's what the routing information for computer A might look like:

Network       Router        Metric 128.6.4       none            0 128.6.21      128.6.4.1       1 128.121       128.6.4.1       2

From this table, computer A can tell that datagrams for computers on network 128.6.4 can be sent directly, and datagrams for computers on networks 128.6.21 and 128.121 need to be sent to router R for forwarding. The "metric" is used by some routing algorithms as a measure of how far away the destination is. In this case, the metric simply indicates how many routers the datagram has to go through. (This is often referred to as a "hop count"). When computer A is ready to send a datagram, it examines the destination address. It gets the network number from the beginning of the address, and then looks in the routing table. The table entry indicates whether the datagram should be sent directly to the destination or to a router. Note that a router is simply a computer that is connected to two different networks, and is prepared to forward datagrams between them. In many cases it is most efficient to use special-purpose equipment that are designed as routers. However it is perfectly possible to use ordinary computers, as long as they have more than one network interface, and their software is prepared to forward datagrams. Most major TCP/IP implementations (even for microcomputers, as KA9Q and PCRoute) are designed to let you use your computer as a router. However some of this software has limitations that can cause trouble for your network. Note that a router has several addresses: one for each network that it's attached to. This is a difference between IP and some other network protocols: each interface from a computer to a network has an address. With some other protocols, each computer has only one address, which applies to all of its interfaces. A router between networks 128.6.4 and 128.6.21 will have an address that begins with 128.6.4 (for example, 128.6.4.1). This address refers to its connection to network 128.6.4. It will also have an address that begins with 128.6.21 (for example, 128.6.21.2). This refers to its connection to network 128.6.21. The term "network" probably makes you think of things like Ethernet, which can have many machines attached. However it also applies to point to point lines. In the diagram above, networks 1 and 3 could be in different cities. Then network 2 could be a serial line, satellite link, or other long-distance point to point connection between the two locations. A point to point line is treated as a network that just happens to have only two computers on it. As with any other network, the point to point line has a network number (in this case 128.6.21). The systems connected by the line (routers R and S) have addresses on that network (in this case 128.6.21.1 and 128.6.21.2). It is possible to design routing software that does not require a separate network number for each point to point line. In that case, the interface between the router and the point to point line doesn't have an address. This can be useful if your network is so large that you are in danger of running out of network numbers. However such "anonymous interfaces" can make network management somewhat more difficult. If there is no address, network management software may have no way to refer to the interface. Thus you may not be able to get data on throughput and errors for that interface.

The first comment to make about addresses is a warning: Before you start using an IP network, you must get one or more official network numbers. IP addresses look like this: 128.6.4.3. This address is used by one computer at Rutgers University. The first part of it, 128.6, is a network number, allocated to Rutgers by a central authority. Before you start allocating addresses to your computers, you must get an official network number. Unfortunately, some people set up networks using either a randomly-chosen number, or a generic number supplied by the vendor. While this may work in the short run, it is a very bad idea for the long run. Eventually, you will want to connect your network to some other organization's network. Even if your organization is highly secret and very concerned about security, somewhere in your organization there is going to be a research computer that ends up being connected to a nearby university. That university will probably be connected to a large-scale national network. As soon as one of your datagrams escapes your local network, the organization you are talking to is going to become very confused, because the addresses that appear in your datagrams are probably officially allocated to someone else. The solution to this is simple: get your own network number from the beginning. It costs nothing. If you delay it, then sometime years from now you are going to be faced with the job of changing every address on a large network. Network numbers are currently assigned by the Network Information Center (NIC). The main piece of information that will be needed when you apply for a network number is the address class that you want. See below for a discussion of this. In many ways, the most important decision you have to make in setting up a network is how you will assign IP addresses to your computers. This choice should be made with a view of how your network is likely to grow. Otherwise, you will find that you have to change addresses. When you have several hundred computers, address changes can be nearly impossible. Addresses are critical because IP datagrams are routed on the basis of their address. For example, addresses at Rutgers University have a 2-level structure. A typical address is 128.6.4.3. 128.6 is assigned to Rutgers University. As far as the outside world is concerned, 128.6 is a single network. Other universities send any datagram whose address begins with 128.6 to the nearest Rutgers router. However within Rutgers, we divide up our address space into "subnets". We use the next 8 bits of address to indicate which subnet a computer belongs to. 128.6.4.3 belongs to subnet 128.6.4. Generally subnets correspond to physical networks, e.g. separate Ethernets, although we will see some exceptions later. Systems inside Rutgers, unlike those outside, contain information about the Rutgers subnet structure. So once a datagram for 128.6.4.3 arrives at Rutgers, the Rutgers network 5 will route it to the departmental Ethernet, token ring, or whatever, that has been assigned subnet number 128.6.4.

When you start a network, there are several addressing decisions that face you:

      •  Do you subdivide your address space?
      •  If so, do you use subnets or class C addresses?
      •  How big an address space do you need?

2.4 Should address space be subdivided?

It is not necessary to use subnets at all. There are network technologies that allow an entire campus or company to act as a single large logical Ethernet, so that no internal routing is necessary. If you use this technology, then you do not need to subdivide your address space. In that case, the only decision you have to make is what class of address to apply for. However we recommend using either a subnet approach or some other method of subdividing your address space in most networks:

	• In a later section we will argue that internal routers are desirable for all networks beyond the very simplest.
	• Even if you do not need routers now, you may find later that you need to use them. Thus it probably makes sense to assign addresses as if each Ethernet or token ring were going to be a separate subnet. This will allow for conversion to real subnets later if it proves necessary
	• For network maintenance purposes, it is convenient to have addresses whose structure corresponds to the structure of the network. For example, when you see a stray datagram from system 128.6.4.3, it is nice to know that all addresses beginning with 128.6.4 are in a particular building.

2.5 Subnets vs. multiple network numbers: network mask

Suppose that you have been convinced that it's a good idea to impose some structure on your addresses. The next question is what that structure should be. There are two basic approaches. One is subnets. The other is multiple network numbers. The Internet standards specify the format of an address. For addresses beginning with 128 through 191 (the most common numbers these days), the first two octets form the network number. For instance, in 140.3.50.1, 140.3 is the network number. Network numbers are assigned to a particular organization. What you do with the next two octets is up to you. You could choose to make the next octet be a subnet number, or you could use some other scheme entirely. Routers within your organization must be set up to know the subnetting scheme that you are using. However outside your organization, no one will know that 140.3.50 is one subnet and 140.3.51 is another. They will simply know that 140.3 is your organization. Unfortunately, this ability to add additional structure to the address via subnets was not present in the original IP specifications. Thus some older software is incapable of being told about subnets. If enough of the software that you are using has this problem, it may be impractical for you to use subnets. Some organizations have used a different approach. It is possible for an organization to apply for several network numbers. Instead of dividing a single network number, say 140.3, into several subnets, e.g. 140.3.1 through 140.3.10, you could apply for 10 different network numbers. Thus you might be assigned the range 140.3 through 140.12. All IP software will know that these are different network numbers. While using separate network numbers will work just fine within your organization, it has two very serious disadvantages. The first, and less serious, is that it wastes address space. There are only about 16,000 possible class B addresses. We cannot afford to waste 10 of them on your organization, unless it is very large. This objection is less serious because you would normally ask for class C addresses for this purpose, and there are about 2 million possible class C addresses. The more serious problem with using several network numbers rather than subnets is that it overloads the routing tables in the rest of the Internet. As mentioned above, when you divide your network number into subnets, this division is known within your organization, but not outside it. Thus systems outside your organization need only one entry in their tables in order to be able to reach you. E.g. other universities have entries in their routing tables for 128.6, which is the Rutgers network number. If you use a range of network numbers instead of subnets, that division will be visible to the entire Internet. If we used 128.6 through 128.16 instead of subdividing 128.6, other Internet sites would need entries for each of those network numbers in their routing tables. As of this writing the routing tables in many of the national networks are exceeding the size of the current routing technology. It would be considered extremely unfriendly for any organization to use more than one network number. This may not be a problem if your network is going to be completely self-contained, or if only one small piece of it will be connected to the outside world. Nevertheless, most TCP/IP experts strongly recommend that you use subnets rather than multiple networks. The only reason for considering multiple networks is to deal with software that cannot handle subnets. This was a problem a few years ago, but is currently less serious. As long as your routers can handle subnets, you can deal with a few individual computers that cannot by using "proxy ARP".

One warning about subnets: Your subnets must all be "adjacent". That 7 is, you can't have a configuration where you get from subnet 128.6.4 to subnet 128.6.5 by going through some other network entirely, e.g. 128.121. For example, Rutgers has campuses in New Brunswick and Newark. It is perfectly OK for the networks in both cities to be subnets of 128.6. However in that case, the lines beween New Brunswick and Newark must also be part of 128.6. Suppose we decided to use a regional network such as JvNCnet to talk between these two campuses, instead of providing direct lines. Since JvNCnet is 128.121, the routers and serial lines that they provide would have addresses that begin with 128.121. This violate the rules. It is not allowable to have routers or lines that are part of 128.121 connecting two parts of 128.6. So if we wanted to use JvNCnet between the two campuses, we'd have to get different network numbers for the two campuses. (This rule is a result of limitations in routing technology. Eventually router software will probably be developed that can deal with configurations whose networks are not contiguous).

Once you have decided to use subnets or multiple network numbers, you have to decide how to allocate them. Normally this is fairly easy. Each physical network, e.g. Ethernet or token ring, is assigned a separate subnet or network number. However you do have some options. In some cases it may make sense to assign several subnet numbers to a single physical network. At Rutgers there is a single Ethernet that spans three buildings, using repeaters. It is very clear that as computers are added to this Ethernet, it is going to have to be split into several separate Ethernets. In order to avoid having to change addresses when this is done, three different subnet numbers have been allocated to this Ethernet, one per building. (This would be handy even if it is not planned to split the Ethernet, just to help keep track of where computers are). However before doing this, make very sure that the software on all of your computers can handle a network that has three different network numbers on it. This issue is discussed in more detail later. You also have to choose a "subnet mask". This is used by the software on your systems to separate the subnet from the rest of the address. So far we have always assumed that the first two octets are the network number, and the next octet is the subnet number. For class B addresses, the standards specify that the first two octets are the network number. However we are free to choose the boundary between the subnet number and the rest of the address. It's very common to have a one-octet subnet number, but that's not the only possible choice. Let's look again at a class B address, e.g. 128.6.4.3. It is easy to see that if the third octet is used for a subnet number, there are 256 possible subnets and within each subnet there are 256 possible addresses. (Actually, the numbers are more like 254, since it is generally a bad idea to use 0 or 255 for subnet numbers or addresses). Suppose you know that you will never have more than 128 computers on a 8 given subnet, but you are afraid you might need more than 256 subnets, (for example, you might have a campus with lots of small buildings). In that case, you could define 9 bits for the subnet number, leaving 7 bits for addresses within each subnet. This choice is expressed by a bit mask, using ones for the bits used by the network and subnet number, and 0's for the bits used for individual addresses. A typical subnet mask is 255.255.255.0, but if you choose 9 bit subnet numbers and 7 bit addresses, the subnet mask would be 255.255.255.128. Generally it is possible to specify the subnet mask for each computer as part of configuring its IP software. The IP protocols also allow for computers to send a query asking what the subnet mask is. If your network supports broadcast queries, and there is at least one computer or router on the network that knows the subnet mask, it may be unnecessary to set it on the other computers. However this capability brings with it a whole new set of possible problems. One well-known TCP/IP implementation would answer with the wrong subnet mask when queried, thus leading causing every other computer on the network to be misconfigured. Thus it may be safest to set the subnet mask explicitly on each system.

More about subnets
Those organizations with class A and B (and very infrequently class C) network numbers, split their network number into pieces called subnetworks. Each subnet is usually distinct from another by adminstrative splitting between departments or by location (such as several offices of a corporation), or by physical medium (such as Etbernet, Token Ring, or X.25). Then each of these subnets are connected to each other via routers which hook the networks together and, if necessary, translate the protocols or allow different networks media to communicate with each other. Where organizations are using subnets, they decide on how many hosts will be on each subnet and therefore, how many bits of the available local address will be used to designate the subnet number and the host number. For instance, a class B network has the first two bytes in use for network number as assigned from the NIC, and has two bytes, or 16 bits, left to represent its local addresses. If the organition will not have 64,000 hosts on one network, it can decide to use 4 of these bits for the subnet numbers, and the remaining 12 bits for the host numbers. This allows the organization 16 subnets and 2,046 hosts on each subnet. Subnets are most often used to mask the internal structure of a complicated network from others in order to make the task of routing network messages around the Internet much easier. The internal network structure is then complicated, as the hosts on the internal networks need to find out how to route a message from one host to another, but mecanisms have been worked out for this.

When an IP packet is sent from one host to another, its IP destination address is masked by what is known as the subnet mask. The mask is zeros wbere the host number is, and ones over the network and subnet numbers. Therefore, if you had a class B nework with 4 bits of subnet information, the subnet mask would be 255.255.240.0, equivalent to fffff000 in hexadecimal notation. After the IP address is masked with the subnet mask, the revealed portion of the address (the network number plus the subnet number) is compared with the corresponding part of the host's own address. If the revealed sections of the two addresses are different, the destination is assumed to be on another subnet, and the routing algorithms send the packet to the appropriate gateway. If the revealed sections are the same, the destination is assumed to be on the same local area network as the host itself, and the concealed portion of the destination address is used to contruct the proper physical address.

As an example, assume you are using a class B address with 4 bits of subnet, your host number is 128.127.126 101, the destination address is 128.127.126.32. Then using the subnet mask 255.255.240.0, the number 128.127.0.0 is revealed. Since it does not match 128.127.112.0 (remember that both the source and destination addresses must be masked), it is assumed to be on another subnet, and is routed as such. In more graphic form:

    Source address: 128.127.126.101     0                   1                   2                   3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |1 0|                           |0 1 1 1|1 1 1 0 0 1 1 0 0 1 0 1|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            network bits           subnet bits     Destination address: 128.127.1.32     0                   1                   2                   3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |1 0|                           |0 0 0 0|0 0 1 0 0 1 1 0 0 1 0 1|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            network bits           subnet bits

As another example, assume again that you are using a class B address with bits of subnet, and your host number is 128.127.126.101, but the destination address is now 128.127.126.3. Then, using the same subnet mask, the number 128.127.112.0 is revealed. Since it matches the first 2 bytes and the next 4 bits of your address, it is assumed to be on the same subnet, and a protocol such ARP is used to find the physical address for the host. Again, im a more graphic form:

   Source address: 128.127.126.101    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |1 0|                           |0 1 1 1|1 1 1 0 0 1 1 0 0 1 0 1|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               network bits           subnet bits    Destination address: 128.127.126.3    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |1 0|                           |0 1 1 1|1 1 1 0 0 0 0 0 0 0 1 1|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            network bits           subnet bits

2.6 Dealing with multiple virtual subnets on one network

Most software is written under the assumption that every computer on the local network has the same subnet number. When traffic is being sent to a machine with a different subnet number, the software will generally expect to find a router to handle forwarding to that subnet. Let's look at the implications. Suppose subnets 128.6.19 and 128.6.20 are on the same Ethernet. Consider the way things look from the point of view of a computer with address 128.6.19.3. It will have no problem sending to other machines with addresses 128.6.19.x. They are on the same subnet, and so our computer will know to send directly to them on the local Ethernet. However suppose it is asked to send a datagram to 128.6.20.2. Since this is a different subnet, most software will expect to find a router that handles forwarding between the two subnets. Of course there isn't a router between subnets 128.6.19 and 128.6.20, since they are on the same Ethernet. Thus you have to find a way to tell your software that 128.6.20 is actually on the same Ethernet. Most common TCP/IP implementations can deal with more than one subnet on a network. For example, Berkeley UNIX lets you use a slight modification of the command used to define routers. Suppose that you get from subnet 128.6.19 to subnet 128.6.4 using a router whose address is 128.6.19.1. You would use the command:

route add     128.6.4.0     128.6.19.1    1

This says that to reach subnet 128.6.4, traffic should be sent via the router at 128.6.19.1, and that the route only has to go through one router. The "1" is referred to as the "routing metric". If you use 9 a metric of 0, you are saying that the destination subnet is on the same network, and no router is needed. In our example, on system 128.6.19.3, you would use.

route add     128.6.20.0    8.6.19.1      0

The actual address used in place of 128.6.19.1 is irrelevant. The metric of 0 says that no router is actually going to be used, so the router address is not used. However it must be a legal address on the local network. Note that the commands in this section are simply examples. You should look in the documentation for your particular implementation to see how to configure your routing.

Turning off subnetting
There is another way to handle several subnets on one physical network. This method involves intentionally misconfiguring your hosts, so it is potentially dangerous if you don't watch what you are doing. However it may be easier to deal with when you have lots of subnets on one physical network. An example of this is a site that uses bridges, and uses subnets simply for administrative convenience. The trick is to configure the software on your hosts as if you were not using subnets at all. In this case your hosts will not make any distinction between the subnets, and they'll have no trouble dealing with all of them. Now the only problem is how to talk to subnets that are not on this multi-subnet network. However if your routers handle proxy ARP, they will solve that problem for you. This approach is likely to be convenient when the same network is carrying many subnets, particularly if additional ones are likely to be added later. However it has two problems: If you have any hosts with multiple interfaces, you will have to be very careful. First, only one interface should be on the multi-subnet network. For example, suppose you have a "network" that is made up of several Ethernets connected by bridges. You can't have a machine with interfaces on two of those Ethernets. However you can have a system with one interface on the multi-subnet network and another on some totally separate subnet. Second, any machine with multiple interfaces will have to know the real subnet mask, and will need to be told explicitly which subnets are on the multi-subnet network. These restrictions come about because a system with multiple interfaces has to know which interface to use in any given case. You will have to be careful about the ICMP subnet mask facility. This is a facility that allows systems to broadcast a query asking what the subnet mask is. If most of your hosts think the network is not subnetted, but your routers and multi-interface hosts think it is, you've got a potential for confusion. If a router or multi-interface host happens to send an ICMP subnet mask reply giving the real subnet mask, some of your other hosts may pick it up. The reverse is 10 possible as well. This means that you will either have to - disable ICMP subnet mask replies on all of the systems that know the real subnet mask. (This may be easy if only routers know it). - make sure that your hosts ignore ICMP replies. According to the most recent documents, as long as you set the subnet mask explicitly, hosts are supposed to ignore the ICMP subnet mask mechanism. So you should be able to set different masks on different hosts without causing any problem, as long as you set the mask explicitly for all of them. However, it has been noticed that some IP implementations will change their subnet mask when they see an ICMP subnet mask reply.

Multiple subnets: implications for broadcasting
When you have more than one subnet on the same physical network, you need to give some thought to broadcast addresses. According to the latest standards, there are two different ways for a host on subnet 128.6.20 to send a broadcast on the local network. One is to use address 128.6.20.255. The other is to use address 255.255.255.255. 128.6.20.255 says explicitly "all hosts on subnet 128.6.20". 255.255.255.255 says "all hosts on my local network". Normally these have the same effect. However they do not when there are several subnets on one physical network. If subnet 128.6.19 is on the same Ethernet, it is also going to receive messages sent to 255.255.255.255. However hosts with numbers 128.6.19.x will not listen to broadcasts to 128.6.20.255. The result is that the two different forms of broadcast address will have somewhat different meanings. This means that you will have to exercise some care in configuring software on networks such as this, to make sure that broadcasts go where you intend them to go.

2.7 Choosing an address class

When you apply for an official network number, you will be asked what class of network number you need. The possible answers are A, B, and C. This affects how large an address space you will be allocated. Class A addresses are one octet long, class B addresses are 2 octets, and class C addresses are 3 octets. This represents a tradeoff: there are a lot more class C addresses than class A addresses, but the class C addresses don't allow as many hosts. The idea was that there would be a few very large networks, a moderate number of medium-size ones, and a lot of mom-and-pop stores with small networks. For example network 10, a class A network, has addresses between 10.0.0.1 and 10.255.255.254. So it allows 2543, or about 16 million possible addresses. (Actually, network 10 has allocated addresses where some of the octets are zero, so there are a few more addresses possible). Network 192.12.88, a class C network has hosts between 192.12.88.1 and 192.12.88.254, i.e. 254 possible hosts. In general, you will be expected to choose the lowest class that will provide you with enough addresses to handle your growth over the next few years. Organizations that have computers in many buildings will probably need and be able to get a class B address, assuming that they are going to use subnetting. (If you are going to use many separate network numbers, you would ask for a number of class C addresses). Class A addresses are normally used only for large public networks and for a few very large corporate networks.

2.8 Dialup IP and dynamically assigned addresses

In most cases, each of your computers will have its own permanent IP address. However there are a few situations where it makes more sense to allocate addresses dynamically. The most common cases involve dialup IP, and routers intended primarily for microcomputers.

It is possible to run IP over dialup lines. The protocols for doing so is called SLIP (Serial Line IP) and PPP (Point to Point Protocol). SLIP is useful in at least two different circumstances:

As a low-cost alternative to permanent point to point lines, for cases where there isn't enough traffic to justify dedicated lines.

As a way to connect individual PC's into a network when they are located in buildings that don't have Ethernets or other LAN technology. We are going to use the term "checking".

Security own their do network the over access they that applications where and pc's, of lot a have you addresses dynamic using recommend we transactions. Sensitive other in engage or mail, computer private receive to going is pc if case be would this to. Talking are which tell able computers cases permanent pc's giving address. Out figure how on agree your server slip want, way assigns it sure make carefully. Software check need developed, standard such until yet. single isn't there but them, handle implementations several slip. With issues addressing these manage no unfortunately, files. All steal yours claim his could someone otherwise needed. care some is. Address its what for has server, connects when problem: reverse address, each use. include scheme, use assign. Can track keeps ip range give simplest pc. Unused an finds first dynamically. assign many problems, avoid order subnet. One addresses, two servers, both call wanted user difficult. More even will subnet, than servers can't that, available so 256 only generally server. As subnet same get systems dialup straight, routing keep addresses. Enough not just may thing, practical often slip, up dialing individual number connect networks users into router provide system attached, modems refer server, when you are using SLIP to connect two networks, you have three choices for handling addressing (although not all SLIP software can handle all three choices):

Treat SLIP connections like point to point lines that just don't happen to be up all the time. If you call more than one computer, each pair of computers that talks has a separate network number which they use only when they talk to each other.

Use routing software that allows anonymous interfaces. In that case no address is needed at all.

Assign addresses dynamically when the connection is opened, just as you would for a PC that is dialing up.

If you make connections only to one or two other systems, it is quite reasonable to use a network number for each connection. This method makes it easy to keep usage and error statistics. If you have many different connections, it is probably best to use anonymous interfaces. You would probably use dynamic address allocation only if your routing technology did not support anonymous interfaces.