</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P><B><I>Meaning</I></B>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>0

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>No priority specified

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>1

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Background traffic

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>2

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Unattended data transfer

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>3

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Unassigned

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>4

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Attended bulk transfer

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>5

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Unassigned

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>6

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Interactive traffic

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>7

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Control traffic</FONT>

</TABLE></CENTER><BR>

<P>Noncongestion controlled traffic has priorities 8 through 15 available, but as I mentioned earlier, they are not defined.

<BR>

<P>Examples of each of the primary subcategories might help you see how the datagrams are prioritized. Routing and network management traffic that is considered highest priority is assigned category 7. Interactive applications such as Telnet and remote X sessions are assigned as interactive traffic (category 6). Transfers that are not time-critical (such as Telnet sessions) but are still controlled by an interactive application such as FTP are assigned as category 4. E-mail is usually assigned as category 2, whereas low-priority material such as news is set to category 1.

<BR>

<BR>

<A ID="E70E21" NAME="E70E21"></A>

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Flow Labels</B></FONT></CENTER></H5>

<BR>

<P>As mentioned earlier, the Flow Label field new to the IPng header can be used to help identify the sender and destination of many IP datagrams. By employing caches to handle flows, the datagrams can be routed more efficiently. Not all applications can handle flow labels, in which case the field is set to a value of 0.

<BR>

<P>A simple example might help show the usefulness of the flow label field. Suppose a PC running Windows 95 is connected to a UNIX server on another network and is sending a large number of datagrams. By setting a specific value of the flow label for all the datagrams in the transmission, the routers along the way to the server can assemble entries in their routing caches that indicate which way to route each datagram with the same flow label. When subsequent datagrams with the same flow label arrive, the router doesn't have to recalculate the route; it can simply check the cache and extract the saved information from that. This speeds up the passage of the datagrams through each router.

<BR>

<P>To prevent caches from growing too large or holding stale information, IPng stipulates that the cache maintained in a routing device cannot be kept for more than six seconds. If a new datagram with the same flow label is not received within six seconds, the cache entry is removed. To prevent repeated values from the sending machine, the sender must wait six seconds before using the same flow label value for another destination.

<BR>

<P>IPng allows flow labels to be used to reserve a route for time-critical applications. For example, a real-time application that has to send several datagrams along the same route and needs as rapid a transmission as possible (such as is needed for video or audio, for example) can establish the route by sending datagrams ahead of time, being careful not to exceed the six second time-out on the interim routers.

<BR>

<BR>

<A ID="E69E54" NAME="E69E54"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>128-Bit IP Addresses</B></FONT></CENTER></H4>

<BR>

<P>Probably the most important aspect of IPng is its capability to provide for longer IP addresses. IPng increases the IP address from 32 bits to 128 bits. This enables an incredible number of addresses to be assembled, probably more than can ever be used.

<BR>

<P>The new IP addresses support three kinds of addresses: unicast, multicast, and anycast.

<BR>

<UL>

<LI>Unicast addresses are meant to identify a particular machine's interface. This lets a PC, for example, have several different protocols in use, each with its own address. Thus, you could send messages specifically to a machine's IP interface address and not the NetBEUI interface address.

<BR></LI>

<BR>

<LI>A multicast address identifies a group of interfaces, enabling all machines in a group to receive the same packet. This is much like broadcasts in IP version 4, although with more flexibility for defining groups. Your machine's interfaces could belong to several multicast groups.

<BR></LI>

<BR>

<LI>An anycast address identifies a group of interfaces on a single multicast address. In other words, more than one interface can receive the datagram on the same machine.

<BR></LI>

<BR>

</UL>

<P>The handling of fragmentation and reassembly is also changed with IPng to provide more capabilities for IP. Also proposed for IPng is an authentication scheme that can ensure that the data has not been corrupted between sender and receiver, as well as ensuring that the sending and receiving machines are who they claim they are.

<BR>

<BR>

<A ID="E69E55" NAME="E69E55"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>IP Extension Headers</B></FONT></CENTER></H4>

<BR>

<P>IPng has the provision to enable additional headers to be tacked onto the IP header. This might be necessary when a simple routing to the destination is not possible, or when special services such as authentication are required for the datagram. The additional information required is packaged into an extension header and appended to the IP header.

<BR>

<P>IPng defines several types of extension headers identified by a number placed in the Next Header field of the IP header. The currently accepted values and their meanings were shown in Table 3.3. Several extensions can be appended onto one IP header, with each extension's Next Header field indicating the next extension. Normally, the extension headers are appended in ascending numerical order. This makes it easier for routers to analyze the extensions, stopping the examination when it gets past router-specific extensions.

<BR>

<BR>

<A ID="E70E22" NAME="E70E22"></A>

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Hop-by-Hop Headers</B></FONT></CENTER></H5>

<BR>

<P>Extension type 0 is hop-by-hop, which is used to provide IP options to every machine the datagram passes through. The options included in the hop-by-hop extension have a standard format of a Type value, a Length, and a Value (except for the Pad1 option, which has a single value set to 0 and no length or value field). Both the Type and Length fields are a single byte in length, whereas the Value field's length is variable and indicated by the length byte.

<BR>

<P>There are three types of hop-by-hop extensions defined so far, called Pad1, PadN, and Jumbo Payload. The Pad1 option is a single byte with a value of 0, no length, and no value. It is used to alter the order and position of other options in the header when necessary, dictated usually by an application. The PadN option is similar except it has N zeros placed in the Value field and a calculated value for the length.

<BR>

<P>The Jumbo Payload extension option is used to handle datagram sizes in excess of 65,535 bytes. The Length field in the IP header is limited to 16 bits, hence the limit of 65,535 for the datagram size. To handle larger datagram lengths, the IP header's Length field is set to 0, which redirects the routers to the extension to pick up a correct length value. The Length field can be defined in the extension header using 32 bits, which is in excess of 4 terabytes.

<BR>

<BR>

<A ID="E70E23" NAME="E70E23"></A>

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Routing Headers</B></FONT></CENTER></H5>

<BR>

<P>A routing extension can be tacked onto the IP header when the sending machine wants to control the routing of the datagram instead of leaving it to the routers along the path. The routing extension can be used to give routes to the destination. The routing extension includes fields for each IP address along the desired route.

<BR>

<BR>

<A ID="E70E24" NAME="E70E24"></A>

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Fragment Headers</B></FONT></CENTER></H5>

<BR>

<P>The fragment header can be appended to an IP datagram to enable a machine to fragment a large datagram into smaller parts. Part of the design of IPng was to prevent subsequent fragmentation, but in some cases fragmentation must be enabled in order to pass the datagram along the network.

<BR>

<BR>

<A ID="E70E25" NAME="E70E25"></A>

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Authentication Headers</B></FONT></CENTER></H5>

<BR>

<P>The authentication header is used to ensure that no alteration was made to the contents of the datagram and that the datagram originated at the machine shown in the IP header. By default, IPng uses an authentication scheme called Message Digest 5 (MD5). Other authentication schemes can be used as long as both ends of the connection agree on the same scheme.

<BR>

<P>The authentication header consists of a security parameters index (SPI) that, when combined with the destination IP address, defines the authentication scheme. The SPI is followed by authentication data, which with MD5 is 16 bytes long. MD5 starts with a key (padded to 128 bits if it is shorter), then appends the entire datagram. The key is then tagged at the end, and the MD5 algorithm is run on the whole. To prevent problems with hop counters and the authentication header itself altering the values, they are zeroed for the purposes of calculating the authentication value. The MD5 algorithm generates a 128-bit value that is placed in the authentication header. The steps are repeated in reverse at the receiving end. Both ends must have the same key value, of course, for the scheme to work.

<BR>

<P>The datagram contents can be encrypted prior to generating authentication values using the default IPng encryption scheme, called Cipher Block Chaining (CBC), part of the Data Encryption Standard (DES).

<BR>

<BR>

<A ID="E68E31" NAME="E68E31"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Internet Protocol Support in Different Environments</B></FONT></CENTER></H3>

<BR>

<P>The University of California at Berkeley was given a grant in the early 1980s to modify their UNIX operating system to included support for IP. The BSD4.2 UNIX release already offered support for TCP and IP, as well as the Simple Mail Transfer Protocol (SMTP) and Address Resolution Protocol (ARP), but with DARPA's funds, BSD4.3 was developed to provide more complete support.

<BR>

<P>The BSD4.2 support for IP was quite good prior to this grant, but it was limited to use in small local area networks only. To increase the capabilities of BSD UNIX's IP support, BSD added retransmission capabilities, Time to Live information, and redirection messages. Other features were added, too, enabling BSD4.3 to work with larger networks, internetworks (connections between different networks), and wide area networks connected by leased lines. This process brought the BSD UNIX system (and its licensees, such as Sun's SunOS) in line with the IP standards used on AT&amp;T UNIX and other UNIX-based platforms.

<BR>

<P>With the strong support for IP among the UNIX community, it was inevitable that manufacturers of other software operating systems would start to produce software that allowed their machines to interconnect to the UNIX IP system. Most of the drive to produce IP versions for non-UNIX operating systems was not because of the Internet (which hadn't started its phenomenal growth at the time) but the desire to integrate the other operating systems into local area networks that used UNIX servers.

<BR>

<P>This section of today's material examines several hardware and software systems, focusing on the most widely used platforms, and shows the availability of IP (and entire TCP/IP suites) for those machines. Much of this is of interest only if you have the particular platform discussed (DEC VAX users tend not to care about interconnectivity to IBM SNA platforms, for example), so you can be selective about the sections you read. In some cases, I use one IP package from some of these platforms as an example and for screen captures later in this book.

<BR>

<BR>

<A ID="E69E56" NAME="E69E56"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>MS-DOS</B></FONT></CENTER></H4>

<BR>

<P>PCs came onto the scene when TCP/IP was already in common use, so it was not surprising to find interconnection software rapidly introduced. In many ways, the PC was a perfect platform as a stand-alone machine with access through a communications package to other larger systems. The PC was perfect for a client/server environment.

<BR>

<P>There are many PC-based versions of TCP/IP. The most widely used packages come from FTP Software, The Wollongong Group, and Beame and Whiteside Software Inc. All the packages feature interconnection capabilities to other machines using TCP/IP, and most add other useful features such as FTP and mail routing.

<BR>

<P>FTP Software's PC/TCP is one of the most widely used. PC/TCP supports the major network interfaces: Packet Driver, IBM's Adapter Support Interface (ASI), Novell's Open Data Link Interface (ODI), and Microsoft/3Com's Network Driver Interface Specification (NDIS). All four LAN interfaces are discussed in more detail in the section titled &quot;Local Area Networks&quot; later today.

<BR>

<P>The design of PC/TCP covers all seven layers of the OSI model, developed in such a manner that components can be configured as required to support different transport mechanisms and applications. Typically, the Packet Driver, ASI, ODI, or NDIS module has a generic PC/TCP kernel on top of it, with the PC/TCP application on top of that.

<BR>

<P>PC/TC