::::::::::::::::::::::::::::::::::::::::::::::::::::::::May/99
::: The Discordant Opposition Journal ::: Issue 5 - File 5 :::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:Protocols and Such:
 Digital Avatar

The internet and all the glorious resources out there would have been
strictly prohibited (until a different solution came along) if TCP/IP
would not have been developed. This is really everything that makes it 
work. Without it, connecting to other computers would be many, many
times more a task than it is.

Perhaps no organization has more complex networking requirements than
the U.S. Department of Defense. Simply enabling communication among
the wide variety of computers found in the various services is not 
enough. DoD computers often need to communicate with contractors and
organizations that do defense-related research, such as universities.

Defense-related network components must be capable of withstanding
considerable damage so that the nation's defenses remain operable
during a disaster. TCP/IP enables such communication, regardless of
vendor or hardware differences, to occur. The fact that the DoD 
initiated research into networking protocols (investigating the 
technology now known as packet switching) is not surprising. In 
fact, research on the protocols that eventually became the TCP/IP 
protocol suite began in 1969. 

There were several important goals for this research. These goals 
are the foundation of TCP/IP.

Common Protocols;

The DoD required a common set of protocols (communications rules) 
that could be specified for all networks. Common protocols would 
greatly simplify the procurement process because the systems could 
communicate with each other.

Interoperability;

If equipment from various vendors could interoperate, the system 
development efficiency could be improved and competition among 
vendors would be promoted. 

Robust Communication;

A particularly dependable network standard was required to meet the 
nation's defense needs. These protocols needed to provide reliable, 
high-performance networking with the relatively primitive wide area 
network technologies then available.

Ease of Reconfiguration;

Because the DoD depended on the network, reconfiguring the network 
and adding and removing computers without disrupting communication 
needed to be possible. 

In 1968, the DoD Advanced Research Project Agency (then called DARPA, 
but since renamed ARPA) initiated research into networks using the
technology now called packet switching — the capability to address a 
packet and move it to the destination through different networks. The 
first experimental network connected four sites: the University of 
California at Los Angeles (UCLA), the University of California at Santa 
Barbara (UCSB), the University of Utah, and SRI International. Early 
tests were encouraging, and additional sites were connected to the 
network. The ARPAnet, as it came to be called, incorporated 20 hosts 
by 1972. 

NOTE: You will encounter the terms Internet and internet, and should 
be aware of an important distinction between them. An internet (short 
for internetwork) is any network comprised of multiple, interconnected 
networks, normally within one company (also referred to as an intranet). 
The Internet is the global internetwork that traces its lineage back to 
the ARPAnet. 

In 1986, groundwork was laid for the commercialization of the ARPAnet. 
The ARPAnet backbone was dismantled, replaced by a network funded by 
the National Science Foundation. NSFnet now functions as the Internet 
backbone. The Advanced Network Services (ANS) manages the NSFnet. The 
initial set of TCP/IP protocols was developed in the early '80s. These 
protocols became the standard protocols for the ARPAnet in 1983. The 
protocols gained popularity in the user community when TCP/IP was 
incorporated into version 4.2 of the BSD (Berkeley Standard 
Distribution) UNIX. The BSD version of UNIX is used widely in educational 
and research institutions. It became the foundation of several commercial 
UNIX implementations, including Sun's SunOS and Digital's Ultrix. Because 
BSD UNIX established a relationship between TCP/IP and the UNIX operating 
system, the vast majority of UNIX implementations now incorporate TCP/IP. 

Many different people were involved in the development of the TCP/IP 
protocol suite. This presented a need to facilitate the sharing of ideas. 
A process did evolve that enabled everyone to comment on the proposed 
definitions of the different standards. Basically, someone would draft 
a standard and the document would be published for review. This became 
the Request for Comments (RFC) process. 

On its way to becoming a standard, a protocol passes through different 
stages. The protocol starts as a Proposed Standard. It may be promoted 
to a Draft Standard, and finally to a full-fledged Standard, an official 
standard protocol for the Internet. At each stage, the protocol faces 
review, debate, implementation, and testing. Proposed Standards, for 
example, go through at least six months of review before they may be 
promoted to a Draft Standard. In general, promoting a standard requires 
two independent implementations of the protocol. 

Obviously this process would break down if no one actually monitored it 
and made decisions when required. The body that takes care of this for 
the TCP/IP protocol is the Internet Activities Board (IAB). The IAB 
coordinates design, engineering, and management of the Internet. The IAB 
has two task forces: the Internet Engineering Task Force (IETF) and the 
Internet Research Task Force (IRTF). Unlike other groups, the IAB is 
made up of volunteers rather than the government, DoD, or a commercial 
vendor. 

Two organizations work with the IAB: the Federal Networking Council and 
the Internet Society. The Federal Networking Council represents all 
agencies of the United States federal government involved with the 
Internet. The Internet Society is a public organization that takes its 
membership from the entire Internet community. Both organizations 
provide input on Internet policy and standards. 

The IETF is responsible for specifying the Internet protocols and 
architecture. By its own description, the IETF is not a traditional 
standards organization, although many specifications produced become 
standards. The IETF is made up of volunteers who meet three times a 
year to fulfill the IETF mandate. The IETF has no membership. Anyone may 
register for and attend meetings. The work of the IETF is organized into 
various areas that change over time. The one consistent factor is the 
IETF's role as the testing and implementation arm for TCP/IP growth and 
development. 

In recent years, new technologies have appeared rapidly on the Internet. A 
case in point is the World Wide Web, which depends on the HyperText Transfer 
Protocol (HTTP). The web and HTTP were in wide use long before RFC 1945 
established an Internet standard for HTTP version 1.0. Increasingly, 
evolution of the Internet is being led by network heavy hitters such as 
Microsoft and Netscape. The slow standards process fails to satisfy vendors 
who want to establish themselves as leaders on the Net.

The only other serious work that has been done comes from the International 
Standards Organization in the form of the Open Systems Interconnection (OSI). 
OSI is another set of protocols that provides a similar functionality to 
TCP/IP.  It was widely assumed that they would replace TCP/IP as the open 
protocol solution, but this has not come to pass. One obstacle with the 
OSI protocols is the fact that they are governed by international bodies, 
which sometimes slows down the development process.

------
A Few Services and protocols associated with TCP/IP:

Telnet - A remote terminal emulation protocol that enables clients to log 
on to remote hosts on the network. 

FTP - A file transfer application that enables users to transfer files 
between hosts. Stands for the File Transfer Protocol.  

SNMP - Used to remotely manage network devices. Stands for the Simple Network 
Management Protocol.  

DNS - Provides meaningful names like achilles.mycorp.com for computers to 
replace numerical addresses like 123.23.32.23. Stands for the Domain Name 
System. 

HTTP - This protocol, the core of the World Wide Web, facilitates retrieval 
and transfer of documents. Stands for the HyperText Transfer Protocol. 
------

To make TCP/IP work, each and every device on a TCP/IP network requires a 
unique address. An IP address identifies the device to all the other devices 
on the network. IP addresses are made up of two parts. The first part of an 
IP address identifies your network ID. With the Internet spanning the entire 
globe, every network or part of a network must have a unique ID. This ID is 
used to route the information being sent to the correct network. The other 
part of your IP address is the host ID, a unique number that identifies each 
computer and device on your network that talks using TCP/IP. 

A TCP/IP address is, simply put, a 32-bit binary number. Looking at an address 
as 32 zeros or ones is difficult for humans, so we view the address as a dotted 
decimal address in the following format: 198.53.147.153. Each of the four 
numbers represents 8 bits of the address and is referred to as an octet. 

Three main classes of addresses exist: Classes A, B, and C. The most obvious 
difference between the three main types of addresses is the number of octets 
used to identify the network ID. 

Class A uses the first octet only; this leaves 24 bits (or three octets) to 
identify the host. Class B uses the first two octets to identify the network, 
leaving 16 bits (two octets) for the host. Class C uses three octets for the 
network ID, leaving 8 bits (one octet) for the host.

Class A: 72.0.0.0

Class B: 112.34.0.0

Class C: 198.173.202.0

A couple of rules determine what you can and cannot use for addresses. Neither 
the network ID nor the host ID can be represented by all 0's or by all 1's, 
because each of these conditions has a special meaning. 

Knowing that the first octet represents the first 8 bits of the address, and 
by knowing the starting bits for the classes of addresses, you can see the 
first octet ranges for the respective classes in the table below.

Note that Class A does not start with 00000000, since that network ID has a 
special meaning, and does not end with 01111111 (decimal 127) since that is 
reserved for loop back. Because the Class A addresses use only the first octet 
to identify the network ID, there are a limited number of them (126; 127 is 
reserved). Each of these 126 networks, however, can have many hosts on it: 2 
to the 24th power (the remaining 24 bits) hosts minus two (the host IDs that 
are all 0's and all 1's) equals 16,777,214 hosts on a single network.

Class B addresses use the first two octets. The first 2 bits, however, are 
set to binary 10. This leaves 14 bits that can be used to identify the 
network: 2 to the 14th possible combinations (6 bits in the first octet and 
8 from the second) 16,384 network IDs (because the first two digits are 10, 
you don't have to worry about an all 0's or all 1's host ID.) 

Each of those network IDs has 16 bits left to identify the host or 65,534 
hosts (2 to the 16th minus 2). Class C networks use three octets (or 24 
bits) to identify the network. The first three bits, however, are always 
110. This means that there are five bits in the first octet and eight in 
each of the other two that can be used to uniquely identify the network 
ID or 2 to the 21st possible networks (2,097,152) each of which has 8 bits 
for hosts or 254 (2 to the 8th minus 2).  

The TCP/IP model for networking has only four layers. Each layer covers 
more functions. They are, Application, Transport, Internet, and Network 
Access. 

The Application layer in TCP/IP combines the functions of both the Application 
and Presentation layers in the OSI model. The Application layer contains 
various services (protocols) such as NNTP (Network News Transfer Protocol) or 
SMTP (Simple Mail Transfer Protocol). The WinSock API is also in the 
Application layer. 

Just as in the OSI model, the Transport layer is the actual language of 
the network. All requests use one of two different transport protocols 
either TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). 
The TCP/IP Internet layer replaces the Network layer in the OSI model. It 
deals not only with finding other hosts (computers) on the same network, 
but with routing information (in the form of packets) to other networks. The 
TCP/IP Network Access layer replaces the Data Link layer. This layer handles 
framing the data and transmitting it to the wire.

TCP/IP does not use computer names in its communications. Rather, it uses 
the IP address of the host as the destination for the packet it will send. 
This means that some method of turning \\comp1 (a NetBIOS computer name) 
or www.microsoft.com (a host name) into an IP address must exist. Otherwise 
you would have to memorize many different IP addresses.

Many different protocols can be located at the Application layer. All the 
TCP/IP protocols (applications) and the NetBIOS services, however, rely on 
the services of two main APIs: WinSock and NetBIOS over TCP/IP (NBT). Windows 
Sockets (WinSock) provides socket-oriented services to the TCP/IP utilities 
that can exist at the Application layer and also provides services to NetBIOS. 
A socket combines a computer's host address with a port number designating a 
service or application running on the computer. The port numbers serve as end 
points for communication between the hosts. 

The port numbers are not normally the same on both ends; services usually use 
well-defined and well-known port numbers. These well-defined port numbers are 
controlled and assigned by the Internet Assigned Numbers Authority. When you 
start a service on your system, the service registers its assigned port number 
in the system and anything that comes in for that port is sent to that service. 
Using port numbers allows the WinSock interface and all the underlying layers 
to ignore what the information is and to just move it from point to point. 

Included in the information is the address, transport layer protocol (UDP or 
TCP), and port number that sent the information; this information enables the 
application to respond directly to that client running on the remote system. 

The first 1,024 ports are reserved and are used only for services. Any port 
number up to 65,536, however, is valid. To look at the whole process, the 
service starts on the server and registers its port number (thereby monitoring 
that port as shown here). On the other host, the client side application starts. 
It also registers a port number that it will use (any available port above 
1023). The client application can now start to send information to the server 
by sending to the IP address, transport protocol, and port number. The server 
then responds to the IP address, protocol, and port number from which it 
received the information.

In this way, there is no reliance on computer names or other upper-level 
information and absolutely no restriction on which port any particular service 
can use. Windows NT uses NetBIOS when you work with its redirector and server 
services (the base Application layer components of Microsoft networking). This 
means that it requires the underlying protocol to handle requests in the forms 
of NetBIOS commands. 

You have just seen that the TCP/IP stack does not use names, nor does it register 
each service with a name/number combination. On the surface, this would seem to 
indicate that NT cannot use TCP/IP for a protocol; but, it does.  To do this, 
another layer has to be brought in that maps (or translates) the NetBIOS command 
into a series of TCP/IP port numbers. This enables the NetBIOS to have a port 
for transmitting and receiving data, establishing and releasing sessions, and 
handling NetBIOS names all over TCP/IP.  

Not surprisingly, the component that handles this function is called NBT or 
NetBIOS over TCP/IP. It is responsible for the mapping of, and communications 
between the NetBIOS interface and the various WinSock ports. This means that 
all communications over TCP/IP must go through the WinSock interface. NBT has 
also been referred to as 
NetBT.

WinSock has to rely on the Transport layer to deal with data moving to and from 
it. This is handled by the two Transport layer protocols: TCP and UDP. Computers 
can have different types of conversations with each other. UDP (User Datagram 
Protocol) provides no guarantee that the packets will get through. TCP 
(Transmission Control Protocol), on the other hand, creates a session, and can 
then guarantee delivery. TCP is used to provide a connection-oriented delivery 
service for the higher-level protocols. 

To do this, TCP must first establish a session with the remote communicating 
host. It does this by means of a three-way handshake. First the host initiating 
the communications sends a packet to the other host that contains information 
about itself and a SYN (or synchronize flag) telling the other host that a 
session is requested. 

The other host receives this packet and responds with information about itself
the SYN flag and an ACK (acknowledgment) of the information that it received. 
Finally the first host ACKs the information it received from the other, and a 
session now exists between the two systems. At the end of the communication 
session, a similar three-way handshake is used to drop the session with the 
remote host. 

This ensures that both of the hosts are through transmitting. It closes the 
session cleanly. Compared to TCP, UDP is simple: The data from the upper-layer 
protocol is encapsulated and sent. UDP is used to send and receive simple 
messages; no session is required. The UDP protocol is used, for example, to 
send and receive broadcast messages. 

The Internet layer has four main protocols. These protocols work together to 
provide a best-effort delivery service (guarantees are the responsibility of 
TCP or higher-level applications). IP (Internet Protocol) needs only to know 
which IP address to send the data to and the protocol on the other system 
(TCP or UDP) that should receive it. 

All devices that use TCP/IP have an Internet layer that includes the routers
that provide the backbone for communications across the network. The IP is 
responsible for taking the packet and determining whether the packet is for 
the local network. If not, the IP must find a route for the packet to the 
destination network and eventually the destination host. 

To understand how the IP determines whether a host is on the local network, 
you must look at the subnet mask and what its function is. As you saw earlier, 
the IP address that each host has is a combination of the network ID and the 
host ID. The address itself is 32 bits long. A varying number of bits are 
used to identify the network and the host. 

The discussion here keeps the subnetting simple and works with the standard
subnet masks. In a later unit, you will look at using custom subnetting and 
supernetting. A logical AND enables you to compare two binary numbers and 
come up with a third that describes the state of the other numbers. What makes 
it important is that you can use it with subnet masks to split an IP address 
into a network ID and a host ID. Address Resolution Protocol (ARP) is now 
used to determine the physical address of the destination host. 

The physical or MAC (Media Access Control) address is used by network adapter
cards to communicate with other network adapter cards on the local network. 
If the destination host is on a remote network, the MAC address of the router 
is used. So ARP, using either its cache of resolved addresses or by broadcast, 
finds the MAC address to send the packet to. In the case of a local machine, 
this is the actual machine. In the case of a remote system, it is the router. 
Remember that the router also has the IP layer and so it has ARP. 

The router finds the MAC address or the host (or another router) on the other 
network. You never receive the information about the other hosts MAC address; 
it would be pointless.After ARP has the address, IP sends the packet to that 
address. Sometimes, however, when talking to hosts on other networks, your 
packet will have problems. When this happens, you receive notification. ICMP 
is a diagnostics and messaging protocol used in the TCP/IP stack to enable 
communications to continue. 

ICMP handles such routine functions as PING. It also handles important issues 
such as reporting unreachable networks. When you are considering a network 
that spans the globe, you have to expect that problems connecting with 
specific hosts will sometimes arise. A few protocols now in place help to 
prevent this. Dynamic Routing is one that provides alternative routes if a 
link goes down. 

Since it may take a long time to try a lot of alternative routes, a time out
value is given to each packet on the Internet. The time out represents the 
maximum number of hops that a packet can make. By default in Windows NT 4.0, 
the Time To Live, or TTL, is 128 seconds. Each router decrements the TTL by 
one for every second that the packet is in the router. If the TTL expires or 
there is no route to the network you are trying to reach, you receive an ICMP 
message (request timed out or destination host unreachable). This prevents 
packets from circulating around the Internet forever, using up bandwidth 
trying to find a route that may not exist. 

ICMP also works to manage the flow of data on the Internet by directing 
traffic. If your router becomes overloaded, for example, and is unable to keep 
up, it might send a source quench message to your system. This tells your 
system to stop sending for a while. Routers also send an ICMP message if they 
detect that a better route to your destination is available. This would be an 
ICMP redirect message, telling your system to use another router. 

IGMP is the last of the protocols that reside in the lower layers of the 
TCP/IP stack. IGMP handles sending and receiving when groups of computers 
are involved. Sending to groups of computers is used to provide the systems 
that receive the information with a live feed. This is multicasting, where 
you get a straight pipe of data.

In multicasting, you send the information from your system to a special IP 
address (a Class D address). You should remember that are Class A, B, and 
C addresses. Class D, however, is only mentioned here; it is not valid as 
a host IP address. When a system multicasts, it chooses an IP address (this 
has to be unique on the network) and sends all the information to that 
address. If you want to receive the information, you must tell your system 
to listen for that address. 

The problem is that your router does not know that it should listen for that 
address, and the packets don't get into your network. IGMP tells your router 
that you wish to listen to that address, enabling you to receive multicasts. 
Just as in the OSI model, the Network Access layer is responsible for framing 
packets of information for the underlying topology and transmitting the data 
on the wire. The Network Access layer also grabs the frames off the network. 
If they are for that MAC address or for broadcast/multicast, the Network 
Access layer passes them up to the appropriate protocol. 

There. Hope you have a little more background on the protocols and services 
out there. 

Peace|Out.
-----
: Digital Avatar :
: lambesis@gmx.net :
: http://damatrix.cjb.net :
