Ebook network certification part 2

267 CHAPTER 7 TCP/IP Upon completion of this chapter, you will be able to: ■ List the layers of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol stack and locate the TCP/IP protocols in the Open Sys- tems Interconnection (OSI) reference model. ■ Understand the function of the Address Resolution Protocol (ARP). ■ Describe the functions of the Internet Control Message Protocol (ICMP). ■ Describe the properties of TCP/IP’s application layer protocols. ■ Understand the functions of a router and describe the information in a routing table. ■ Distinguish between static and dynamic routing. ■ Create a static route in a routing table. ■ Understand the operation of routing protocols. ■ Manually configure TCP/IP client parameters on Microsoft Windows, Novell NetWare, and UNIX/Linux computers. Because of the explosive growth of the Internet in recent years, Transmission Control Protocol/Internet Protocol (TCP/IP) is now used on more networks than any other suite of protocols. In Chapter 5 and Chapter 6 you learned about some of the major protocols in the TCP/IP suite. In this chapter you learn about how the protocols in the suite work together as a whole. Because the TCP/IP pro- tocols are required for Internet communications, virtually all networks use them, so it’s vital for you to understand how they work and how to configure a com- puter to use them. INTRODUCING TCP/IP The TCP/IP protocols were developed in the 1970s specifically for use on a packet-switching network built for the U.S. Department of Defense. That network was known as the ARPANET, which evolved into what is now the Internet. Since 268 NETWORK + CERTIFICATION early in their development, the TCP/IP protocols have also been associated with the UNIX operating systems. Thus, the TCP/IP protocols predate the personal computer (PC), the Open Systems Interconnection (OSI) reference model, the Ethernet protocol, and most of the other elements that are considered the foun- dations of computer networking. Unlike other protocol suites that perform some of the same functions, such as Novell’s Internetwork Packet Exchange (IPX), TCP/IP was never the product of a single company. TCP/IP was a collaborative effort, with the resulting standards being released to the public domain. TCP/IP Development Development of the core TCP/IP protocols began in 1975, when the ARPANET was officially declared to be an operational, rather than experimental, network. In 1983 the protocols were ratified as official standards and were required on all ARPANET systems. By the time development of the TCP/IP protocols began, the developers had enough experience with the ARPANET to understand the basic design principles that should be observed when creating a new protocol suite. These principles are discussed in the following sections. Platform Independence One of the main design principles for the TCP/IP protocols—indeed, the guiding factor for the entire project—was that the protocols must be wholly independent of any particular vendor, computing platform, or hardware specification. Platform independence means that a computer can use any type of processor, run any operating system, and connect to a TCP/IP network using any physical medium available, such as a leased phone line or a dial-up connection. Before the PC became the predominant computing platform, the ARPANET con- sisted of a wide variety of computers that used many technologies to connect to the network. As local area networking became more prevalent and as the ARPA- NET evolved into the Internet, data-link layer protocols such as Ethernet and Token Ring became more popular. The physical layer specifications included with these protocols were also assimilated into the TCP/IP networking standards. Because TCP/IP adapts to any hardware platform, the protocols effectively insu- late the applications running on the networked computers from the physical aspect of the network. A client application on one Ethernet network can use the Internet to connect to a server on another Ethernet network, but the signal might pass through a dozen or more different network types during the journey. The decision to create protocols that are platform independent naturally led the developers to other design principles that became the hallmarks of the TCP/IP protocols. Essentially, creating an independent protocol suite means that no CHAPTER 7: TCP/IP 269 assumptions can be made regarding the computers that will be connected to the network, except that they all must have some physical means to make the required connection. All the other elements needed for computers to communi- cate with each other had to be provided by the protocols. These elements include the following: ■ Each system must have some way to identify itself uniquely to the other systems on the network. ■ Each system must be able to create an interface between the new pro- tocols and the physical medium used to connect to the network. ■ Each system must have a programming interface that enables the requests for network resources issued by the system’s applications to be serviced by use of the new protocols. ■ The new protocols should not limit the growth potential of the network. ■ The standards that define the new protocols should be formatted so that new computing platforms can be easily accommodated. ■ Use of the new protocol standards should not be limited by trade- marks, copyrights, or other publishing restrictions. Addressability A computer on a TCP/IP data communications network must be capable of gen- erating the following three types of data transmissions: ■ Broadcasts Transmissions that are sent to every system on the network ■ Multicasts Transmissions that are sent to a group of systems ■ Unicasts Transmissions that are sent to a single system on the network Broadcast transmissions are the easiest to implement because the data only needs to circulate around the entire network. However, this is also the least efficient method when a transmission is actually intended for only one or a few other sys- tems. The Internet would never have become what it is today if it had relied exclu- sively on broadcast transmissions. The use of unicast and multicast transmissions introduces a critical problem, however. To transmit data to a single destination system or group of systems, there must be a way to uniquely identify that system or group of systems by means of a name or an address. Many of the computing platforms used on the Internet already have an addressing system. For example, 270 NETWORK + CERTIFICATION Ethernet and Token Ring systems both have unique hardware addresses hard- coded into their network interface adapters. These addresses would work well on the Internet, except that not every type of computer has them. Because different types of hardware addresses are used on local networks, the developers of the TCP/IP protocols decided to implement their own addressing system. IP addresses are unique 32-bit binary numbers that are assigned to every interface on the network, in addition to any other hardware addressing system that is in place. This IP address identifies both the network on which the com- puter is located and the individual host system on that network. The efficiency of this IP addressing system has been demonstrated, along with many of TCP/IP’s other features, by the explosive growth of the Internet. At the time of their inception, no one expected the TCP/IP protocols to have to support a network containing the millions of systems in use today, but they are continu- ing to function very well. Another issue that no one anticipated is that all of the possible network addresses would be allocated. That situation is now a possibility, though, and the IP address space is currently being upgraded from 32 to 128 bits. Modularity When TCP/IP was being developed, it became clear that no single monolithic protocol would be able to support all the different computing platforms being used on the ARPANET. The new protocols had to work with existing standards and accommodate all the different physical media used by the networked com- puters, as well any new physical standards that might be developed in the future. The protocols also needed to support a number of different application program- ming interfaces (APIs) so that programs running on different platforms could all request access to the same network resources. The result of these requirements was a series of separate standard documents that define a collection of protocols functioning in four distinct operational lay- ers. Separate protocols were defined for the various physical standards and APIs being used. This method of documenting the protocols has several advantages: ■ Task delegation Separating the support for different physical media and APIs into discrete protocols allows the development tasks to be delegated to people according to their areas of expertise. With separate teams working on the standards for different connection types, the individual protocols can be developed independently, without the need to assemble a group of engineers familiar with both technologies. CHAPTER 7: TCP/IP 271 ■ Quality of service Having multiple protocols operating at the same layer enables applications to select the protocol that provides only the level of service required. ■ Scalability Additional standards documents that adapt the proto- cols to emerging technologies support a steadily increasing number of systems and a growing number of system types. Additional protocol standards that support new physical media and APIs can be developed without modifying the existing protocols. ■ Simultaneous development By using independent teams to work simultaneously on separate areas of the project, the schedule for devel- oping the protocols is accelerated. Mutability is one of the basic tenets on which the Internet and the TCP/IP proto- cols are based. The computing and networking industries are constantly advanc- ing, and technologies are expected to change. The TCP/IP standards are acknowledged to be works-in-progress, with new versions of the documents reg- ularly obsolescing older ones. TCP/IP Standards Another important aspect of the TCP/IP standards is that the documents are freely available to the public, with no limitations on their use, distribution, or publication. This makes it easy for the average administrator to access the source information used to create the TCP/IP implementations found in specific prod- ucts and operating systems. The standards documents can be very valuable, both as learning and troubleshooting tools. Because the TCP/IP standards were designed for use on the fledgling Internet, they were developed and ratified as part of the Internet standardization process, even though they are now used on many private networks. To become an official Internet standard, a document defining a protocol or other technical aspect of TCP/IP must undergo an evaluation and ratification process. During this process, anyone who is interested in contributing to the effort has the opportunity to test it and comment on its contents. The standardization process is governed by the Internet Society (ISOC), which is concerned with all aspects of the Internet’s growth and evolution. ISOC is composed of several subgroups, as follows: ■ Internet Architecture Board (IAB) Technical advisors to ISOC, and the highest level committee involved in the standard ratification process. Consisting of 12 voluntary members, this board performs the final review of a potential standards document before its ratification. 272 NETWORK + CERTIFICATION ■ Internet Engineering Task Force (IETF) Falling under the jurisdic- tion of the IAB, the IETF is the group most directly involved in the tech- nological development and review of potential standards as they proceed through the ratification process. The IETF is composed of eight areas, each of which has one or more Area Directors. Each area is composed of Working Groups that investigate specific technical areas that might result in the development of a standards document or sim- ply work to address a problem. The eight areas of the IETF are as follows: ❑ Applications ❑ Internet ❑ Network Management ❑ Operational Requirements ❑ Routing ❑ Security ❑ Transport ❑ User Services ■ Internet Engineering Steering Group (IESG) Comprised of the chairman of the IETF and the Area Directors of all the Working Groups, the IESG is responsible for moving standards documents through the formal ratification process. The final ratification of an Internet standard comes from the IAB, based on recommendations submitted by the IESG. ■ Internet Assigned Numbers Authority (IANA) An organization devoted to the registration of numerical values that uniquely identify certain protocol specifications used by all implementations of a stan- dard. For example, the IANA assigns the standard port numbers for particular services and prevents those numbers from being duplicated. The IANA also assigns identifying numbers to MIBs (Management Information Bases), protocols, and other elements defined in Internet standards documents. ■ Internet Research Task Force (IRTF) An organization that per- forms long-term investigations of technological issues that aren’t nec- essarily involved in the standards ratification process. The issues might involve emerging technologies that will eventually be passed to the IETF for development of a standard. CHAPTER 7: TCP/IP 273 IETF Membership and Activities Most of the people working in these organizations are volunteers; membership, particularly in the IETF, can be fluid. IETF meetings are held three times annually, and any interested person can register for and attend a meeting or participate in the discussions on the IETF’s Internet mailing lists. Although many of the people in the IETF are employed by firms that are important to the industry surrounding the Internet, their involvement is strictly individual. They do not participate as representatives of their employers, but simply as people interested in the develop- ment and well-being of the Internet. The actual activities of the IETF Working Groups consist of discussions, con- ducted both by mailing lists and in person, that try to achieve what has become the unofficial IETF motto: “Rough consensus and running code.” This means the group tries to come to a general agreement about how to achieve their goal and then tries to realize that goal in concrete terms to prove that it’s a viable solution. MORE INFO IETF Information For more information on the IETF and to access IETF publications and mailing lists, see ietf.org. For a general introduction to the IETF, see Request for Comments (RFC) 3160, “The Tao of IETF—A Novice’s Guide to the Internet Engineering Task Force.” Requests for Comments (RFCs) The published product of the IETF’s work, as well as that of the other bodies gov- erned by ISOC, is a series of documents known as Requests for Comments (RFCs). The IETF maintains a master index of RFCs, which currently lists over 4000 documents dating back to 1969. All of the documents are text files, except for a few that are also available in PostScript (PS) or Adobe Acrobat (PDF) format to facilitate the inclusion of graphical material. All the documents are available for download from the IETF Web site and from dozens of mirror sites around the world. When the IETF publishes an RFC, it assigns a number to the document and lists it in the index. Once an RFC is assigned a number, the version of the document that number represents never changes. When a document is revised, it receives a new number and is republished in its entirety, and older versions are always avail- able. The RFC index is extensively cross-referenced, so you can see when new RFCs make other documents obsolete or when they have been made obsolete by other documents. MORE INFO Accessing the RFC Index The most current version of the RFC index is available at ietf.org/iesg/1rfc_index.txt. 274 NETWORK + CERTIFICATION All the official Internet standards are published as RFCs, but not all RFCs define Internet standards. There are six status indicators for RFCs: three that are devoted to the development and ratification of standards, and three that are used for documents that are not intended to be standards. The latter three RFC status indicators are as follows: ■ Informational A document that’s considered to be of general inter- est to the Internet community but has no implicit endorsement or rec- ommendation from the IETF or any of its related bodies. Although some informational RFCs are technical in nature, many are not, and some are even quite amusing. ■ Experimental A document resulting from a research project (con- ducted by the IRTF or another body) that is not intended or not yet ready for development into a standard. ■ Historic A document that has been made obsolete by another speci- fication and is now of purely historical interest. NOTE Historical Hysteria The IETF, in RFC 2026, “The Internet Stan- dards Process—Revision 3,” acknowledges that the term for the historic document type should properly be historical, not historic, but to quote its author, Scott Bradner, “at this point the use of ‘historic’ is historical.” Informational and experimental documents can be the product of one of the Internet governing bodies, or they can come from outside sources of any type. Before an outside document is published as an informational or experimental RFC, the RFC Editor and the IESG review it. The purpose of this review is to prevent misuse of the RFC publishing process by people who might want to introduce a document and make it appear to be a rat- ified Internet standard, when it is in fact the product of an outside com- pany or organization. The Standardization Process Most of the RFCs that define specific TCP/IP protocols are official Internet stan- dards. Documents that are said to be “on the standards track” are revised and published several times before they are ratified as standards. With these works-in- progress available to the public, they can receive the greatest possible amount of feedback from users. Real-world testing is a major part of the standards develop- ment process. Before becoming RFCs, preliminary versions of standards documents are often published in a separate directory called Internet-Drafts. This directory is a series of temporary documents that are posted for a period of not less than two weeks and not more than six months while being considered for advancement to the CHAPTER 7: TCP/IP 275 standards track. Internet draft documents are removed from the directory when they are approved by the IESG for publication as RFCs. Once published as an RFC, a standard goes through three changes of status on its way to ratification, as follows: ■ Proposed standard The elevation of a document to proposed stan- dard status indicates that it’s on the standards track and that the tech- nology defined in the document is complete and generally stable. However, a proposed standard has not usually been implemented or tested in the field yet. It is recommended that implementations based on the proposed standard be used only in a lab environment because the technology might change significantly before the standard advances to the next stage. A document must remain a proposed stan- dard for at least six months, and two implementations are required before it can be advanced to draft standard status. ■ Draft standard Before a proposed standard can be elevated to draft standard status, it must have two implementations that include all fea- tures and options, and the features and options must be completely interoperable. The technology should also have had sufficient field testing to demonstrate that the document is mature and ready to become an Internet standard with only a minimum of modification. It’s usually safe to develop and deploy production software based on a draft standard because changes will be made only to address specific problems. A document must remain a draft standard for at least four months before it can be granted full Internet standard status. ■ Internet standard Once a draft standard has had sufficient time to demonstrate its stability in extensive operational testing, it can be declared a fully ratified Internet standard. A ratified standard docu- ment is assigned another number, called an STD number, which is independent of the RFC number and remains with the standard even when a new RFC updates it. The document is made available in a sep- arate directory that contains only ratified standards. Each entry in the RFC index is annotated with the document’s current status and with its STD number if the document is an Internet standard. Another way to track the progress of the standardization process is to consult an RFC called “Internet Official Protocol Standards.” This document contains information about the current status of all the RFC documents on the standards track and how to obtain them. This RFC is updated frequently to reflect the latest changes and is always assigned an RFC number that’s a multiple of 100. The current ver- sion of this document as of this writing is RFC 3700, published in July 2004. 276 NETWORK + CERTIFICATION The TCP/IP Protocol Stack The development of the TCP/IP protocols began years before the documents defining the OSI reference model were published, but the protocols use layers in much the same way. Instead of the seven layers used by the OSI model, TCP/IP has its own four-layer networking model, which is defined in RFC 1122, “Require- ments for Internet Hosts—Communication Layers.” The layers are roughly analo- gous to the OSI model, as shown in Figure 7-1. For more information on the OSI model and the functions of its layers, see Chapter 1. Ft07xx01 Figure 7-1 The four TCP/IP protocol layers, compared to the seven-layer OSI reference model The four TCP/IP layers, from bottom to top, are discussed in the following sections. The Link Layer The TCP/IP protocol suite includes two link layer protocols: Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP). SLIP and PPP are used for most wide area network (WAN) connections. However, TCP/IP doesn’t include physical layer specifications of any kind or complex local area network (LAN) protocols such as Ethernet and Token Ring. Therefore, although TCP/IP does maintain a layer that is comparable to the OSI model’s data-link layer, in many cases the protocol operating at that layer isn’t part of the TCP/IP suite. When a TCP/IP system uses SLIP or PPP at the link layer, the protocol stack assumes the presence of a network medium providing the physical connection because SLIP and PPP don’t include physical layer specifications. When the link layer functionality is provided by a non-TCP/IP protocol, such as on a LAN, TCP/ IP assumes the presence of both a valid network medium and a protocol that pro- vides an interface to that medium. Although the TCP/IP standards don’t define the link layer protocol itself on a LAN, there are TCP/IP standards that define the interaction between the internet layer protocol (IP) and the protocol providing the link layer functionality. For example, the use of Ethernet with TCP/IP is gov- erned by standards such as the following: OSI Presentation Application Session Transport Network Data-link Physical TCP/IP Application Transport Internet Link [...]... entry above it, which specifies the system’s network address ■ Entries 5 and 7 The fifth and seventh entries in the sample routing table contain broadcast addresses, both the generic IP broadcast address (25 5 .25 5 .25 5 .25 5) and the local network s broadcast address (1 92. 168 .2. 255) In both of these cases, packets are transmitted to all the computers on the local network, so the system again uses itself as... ( 127 .0.0.1) as the “router” to the destination ■ Entry 3 The IP address of the network interface adapter in the computer to which this routing table belongs is 1 92. 168 .2. 72 Therefore, the third entry in the sample routing table contains the address of the local network on which the computer is located The Network Destination and Netmask values indicate that it’s a Class C network with the address 1 92. 168 .2. 0... address in the Network Destination column and the value 25 5 .25 5 .25 5 .25 5 in the Netmask column 2 If no host address entry exactly matches the Destination IP Address value, the system then scans the routing table’s Network Destination and Netmask columns for an entry that matches the address’s network and subnet identifiers If more than one entry in the routing table contains the desired network and subnet... back to System 1, informing it that it can send packets destined for System 2 directly to Router B 28 5 28 6 NETWORK + CERTIFICATION Router A Hub System 1 Router B Ft07xx04 Figure 7-4 Hub System 2 ICMP Redirect messages The Data field in the ICMP Redirect message contains the usual 28 bytes from the datagram in question (the 20 -byte IP header plus the first 8 bytes of the Data field) plus an additional... Exceeded Pointer Indicates The Error Missing A Required Option 28 3 28 4 NETWORK + CERTIFICATION ICMP Error Messaging Functions Table 7-1 Type Code Function 12 31 32 2 0 0 Bad Length Datagram Conversion Error Mobile Host Redirect The primary function of ICMP is to report errors of various types IP is a connectionless protocol, so no internet /network layer acknowledgments are returned to the sending system... A protocol used to extract information from a directory service, such as Active Directory 29 1 29 2 NETWORK + CERTIFICATION directory service LDAP is based on protocols defined in the X.500 directory service standard, but it is substantially simpler and designed specifically for use on TCP/IP network Much of the network traffic generated by Active Directory logon processes uses LDAP, and the Windows Address... two or more networks that forwards packets from one network to another Routers operate at the network layer of the OSI reference model, so they can connect networks running different data-link layer protocols and different network media On a small internetwork, a router’s job can be quite simple For example, when one router connects two LANs, the router simply receives packets from one network and... fields For Ethernet and Token Ring networks, the value is 6 27 9 28 0 NETWORK + CERTIFICATION ■ Protocol Size (1 byte) Specifies the size, in bytes, of the addresses in the Sender Protocol Address and Target Protocol Address fields For IP addresses, the value is 4 ■ Opcode (2 bytes) Specifies the function of the packet, using one of the following values: ❑ 1 ARP Request ❑ 2 ARP Reply ❑ 3 RARP Request ❑ 4... Type Code Function 3 3 3 3 3 3 3 3 3 3 0 1 2 3 4 5 6 7 8 9 3 10 3 3 4 5 5 5 5 11 11 12 12 11 12 0 0 1 2 3 0 1 0 1 Net Unreachable Host Unreachable Protocol Unreachable Port Unreachable Fragmentation Needed And Don’t Fragment Was Set Source Route Failed Destination Network Unknown Destination Host Unknown Source Host Isolated Communication With Destination Network Is Administratively Prohibited Communication... Multicasting is more complicated, however As discussed in Chapter 5, Class D IP addresses ranging from 22 4.0.1.0 to 23 8 .25 5 .25 5 .25 5 are reserved for multicasting purposes A multicast transmission is simply a packet transmitted to one of those Class D addresses However, determining which systems are part of the multicast group that recognizes that address is a complex process that involves the use of . packet-switching network built for the U.S. Department of Defense. That network was known as the ARPANET, which evolved into what is now the Internet. Since 26 8 NETWORK + CERTIFICATION early. ratification process. Consisting of 12 voluntary members, this board performs the final review of a potential standards document before its ratification. 27 2 NETWORK + CERTIFICATION ■ Internet Engineering. Exceeded In Transit 11 1 Fragment Reassembly Time Exceeded 12 0 Pointer Indicates The Error 12 1 Missing A Required Option 28 4 NETWORK + CERTIFICATION The primary function of ICMP is to report errors