::::::::::::::::::::::::::::::::::::::::::::::::::::::::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 :