Managing TCP/IP Networks P2

Chia sẻ: Khinh Kha Kha | Ngày: | Loại File: PDF | Số trang:20

Thêm vào BST

Báo xấu

102
lượt xem 9
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Now that we have an appreciation for the evolution of the Internet and the TCP/IP protocol suite, let us turn our attention to the structure of the protocol suite. However, since the TCP/IP protocol suite has a layered structure, we will ®rst examine the ISO Reference Model and the subdivision of its second layer by the Institute of Electrical and Electronic Engineers (IEEE) to provide a standardized frame of reference. 2.3 THE ISO REFERENCE MODEL The International Organization for Standardization is an agency of the United Nations headquartered in Geneva, Switzerland. The ISO is tasked with the development of worldwide standards to...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Managing TCP/IP Networks P2

18 THE TCP/IP PROTOCOL SUITE Now that we have an appreciation for the evolution of the Internet and the TCP/IP protocol suite, let us turn our attention to the structure of the protocol suite. However, since the TCP/IP protocol suite has a layered structure, we will ®rst examine the ISO Reference Model and the subdivision of its second layer by the Institute of Electrical and Electronic Engineers (IEEE) to provide a standardized frame of reference. 2.3 THE ISO REFERENCE MODEL The International Organization for Standardization is an agency of the United Nations headquartered in Geneva, Switzerland. The ISO is tasked with the development of worldwide standards to facilitate the international exchange of goods and services. The membership of the ISO consists of the national standards organization of most countries, with over 100 countries participat- ing in its work. One of the most notable achievements of the ISO in the ®eld of data communications was its development of the seven-layer Open Systems Interconnection (OSI) Reference Model. This model de®nes the communica- tions process as a set of seven layers, with speci®c functions isolated and associated with each layer. Figure 2.2 illustrates the seven layers of the ISO Reference Model. Each layer covers lower layer processes, effectively isolating them from higher layer functions. In this way, each layer performs a set of functions necessary to provide a set of services to the layer above it. Layer isolation permits the characteristics of a given layer to change without impacting the remainder of the model, provided that the supporting services remain the same. This layering was developed as a mechanism to enable users to mix and match OSI-conforming communications products to tailor their communications systems to satisfy a particular networking requirement. Although OSI- conforming communications products never gained a signi®cant degree of acceptance, the OSI Reference Model provides a framework for comparing Figure 2.2 The International Organization for Standardization (ISO) Open System Interconnection (OSI) Reference Model
2.3 THE ISO REFERENCE MODEL 19 and contrasting the features and structure of other protocol suites. In addition, by understanding the structure of the model and the subdivision of its second layer by the IEEE, we can also obtain an appreciation of the capabilities and limitations of other protocol suites as well as the manner by which those suites support data ¯ow from source to destination. 2.3.1 Layers of the OSI Reference Model With the exception of layers 1 and 7, each layer in the ISO Reference Model is bounded by the layers above and below it. Layer 1, the physical layer, which is responsible for moving bits in electrical or optical form, can be considered to be bound below by the interconnecting medium over which transmission ¯ows. In comparison, layer 7 is the upper layer and has no upper boundary. Within each layer is a group of functions that can be viewed as providing a set of de®ned services to the layer that bounds it from above, resulting in layer n using the services of layer n-1. To obtain an appreciation of the manner in which the ISO's Reference Model operates, let us turn our attention to each of the layers in the model. Layer 1: the physical layer At the lowest or most basic layer, the physical layer represents a set of rules that speci®es the electrical, optical, and physical connection between devices and the transmission medium. Typically, the physical layer can include the coding method by which data is placed onto the medium as well as the cabling interface to include the operation of different pins on the cabling connection. Layer 2: the data link layer The data link layer de®nes how a device gains access to the medium speci®ed by the physical layer as well as the data formats to include framing, error control procedures, and other link control activities. The data format speci®cation includes procedures employed to correct transmission errors, thus, layer 2 becomes responsible for the reliable delivery of information. At the data link layer information is grouped into entities referred to as frames. As a minimum, each frame contains control information that enables the receiver to synchronize itself to an incoming frame, addressing information that identi®es the source and destination, a ®eld containing the actual information being transmitted from source to destination, and a ®eld used for verifying the integrity of the data. One important characteristic of data link protocols is the fact that they do not have network addresses and as such are non-routable. As we will note later in this chapter, Ethernet, Token-Ring, and FDDI represent examples of data link protocols.
20 THE TCP/IP PROTOCOL SUITE Because the development of OSI layers was originally targeted towards wide area networking, its applicability to local area networks required a degree of modi®cation. Under IEEE 802 standards, the data link layer was subdivided into two sublayers: Logical Link Control (LLC) and Media Access Control (MAC). The LLC layer is responsible for generating and interpreting commands that control the ¯ow of data and perform recover operations in the event of errors. In comparison, the MAC layer is responsible for providing access to the local area network, which enables a station on the network to transmit information. Later in this chapter we will discuss the subdivision in additional detail. Layer 3: the network layer The third layer in the ISO Reference Model is the network layer. As its name implies, this layer is responsible for arranging a logical connection through a network to include the selection and management of a route for the ¯ow of information between source and destination based upon the available paths in a network. Services provided by this layer are associated with the movement of data packets through a network, including addressing, routing, switching, sequencing, and ¯ow control procedures. In a complex network, the source and destination may not be directly connected by a single path, but instead require a path to be established that consists of many subpaths. Thus, routing of data through the network onto the correct paths is an important feature of this layer. Several protocols represent commonly used layer 3 protocols. Those protocols include the X.25 packet protocol, which governs the ¯ow of information within a packet network, Novell's Internet Packet Exchange (IPX), and the Internet Protocol (IP). Layer 4: the transport layer The fourth layer in the ISO's Reference Model is the transport layer. This layer is responsible for guaranteeing that the transfer of information occurs correctly after a route has been established by the network layer protocol. Thus, the primary function of this layer is to control the communications session between nodes once a path has been established by the network control layer. Error control, sequence checking, and other end-to-end data reliability factors are the primary concern of this layer. In addition, to support the transfer of different types of data between source and destination, this layer is also responsible for multiplexing and de-multiplexing data streams between upper layer application processes. Although most transport layer protocols provide an end-to-end reliability mechanism, this is an optional feature associated with this layer. Similarly, although most transport layer protocols are connection-oriented, requiring the destination to acknowledge its ability to receive data prior to a transmission session being established, this is also an optional feature.
2.3 THE ISO REFERENCE MODEL 21 Instead of operating as a connection-oriented protocol, a transport layer protocol can operate on what is referred to as a best-effort basis. This means that the protocol will initiate transmission without knowing if the destination is ready to receive data or even if it is powered on and operational. Although this method of operation may appear awkward, the originator will set a timer that decrements in value. If no response is received to the initial packet ¯ow by the time the timer expires, the originator will assume that the destination is not reachable and terminate the session. The use of a connectionless protocol avoids the relatively long handshaking process associated with some connection-oriented transport layer protocols. Examples of transport layer protocols include Novell's Sequenced Packet Exchange (SPX) as well as the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). TCP is a connection-oriented, error-free delivery protocol. In comparison, UDP is a connectionless, best effort protocol. Layer 5: the session layer The ®fth layer in the OSI Reference Model is the session layer. This layer provides a set of rules for establishing and terminating data streams between nodes in a network. The services that the session layer can provide include establishing and terminating node connections, ¯ow control, dialogue control, and end-to-end data control. Layer 6: the presentation layer The sixth layer in the ISO's OSI Reference Model is the presentation layer. This layer is primarily responsible for formatting, data transformation, and syntax-related operations. One of the primary functions of this layer that is both visible and probably overlooked as we take it for granted is the conversion of transmitted data at the receiver into a display format for a receiving device. Concerning the receiving device, different presentation layers reside on different devices, since the manner in which data is displayed on a PC would more than likely differ from the manner in which data is displayed on a dumb terminal. Other functions that can be performed by the presentation layer include encryption/decryption and compression/ decompression. Layer 7: the application layer The seventh and top layer of the OSI Reference Model is the application layer. This layer can be viewed as functioning as a window through which the application gains access to all of the services provided by the seven-layer model. Examples of functions that can be performed at the application layer include ®le transfer, electronic mail transmission, and remote terminal access.
22 THE TCP/IP PROTOCOL SUITE While the ®rst four layers in the Reference Model are fairly well de®ned, the functions associated with the upper three layers can vary considerably, based upon the application, the type of data transported, and the manner in which the attributes of the display of a device are used for the presentation of information. As we will note later in this chapter, such popular Internet protocols as the File Transfer Protocol (FTP), Telnet, and the HyperText Transport Protocol (HTTP) represent a blend of layer 5 through layer 7 functions. 2.3.2 Data ¯ow As data ¯ows within an ISO network each layer appends appropriate heading information to frames of information ¯owing within the network while removing the heading information added by a lower layer. In this manner, layer n interacts with layer n-1 as data ¯ows through an ISO network. Figure 2.3 illustrates the appending and removal of frame header information as data ¯ows through a network constructed according to the ISO Reference Model. Since each higher level removes the header appended by a lower level, the frame traversing the network arrives in its original form at its destination. 2.3.3 Layer subdivision Prior to examining the major components of the TCP/IP protocol suite, a discussion of layer subdivision resulting from the efforts of the Institute of Electrical and Electronic Engineers (IEEE) is in order. The IEEE is responsible for developing LAN standards in the USA, and its efforts are commonly incorporated by the American National Standards Institute (ANSI) into US standards, either as is or with slight modi®cation. During the early development of LAN standards, the IEEE recognized that it would be desirable to subdivide the data link layer. The result of this subdivision was the creation of Logical Link Control (LLC) and Media Access Control (MAC) sublayers. The MAC sublayer, which resides at the bottom of the portion of the data link layer that was subdivided, de®nes the manner by which a station gains access to a LAN. Examples of MAC methods include Ethernet's Carrier Sense Multiple Access/Collision Detection (CSMA/CD) scheme and Token-Ring's free token acquisition method. Above the MAC layer, which differs for each type of LAN, is the LLC layer. The LLC layer, which is common for each IEEE network, is used for controlling the establishment, maintenance, and termination of logical connections between stations on a network. Addressing Access to an IEEE network is accomplished through the MAC layer. Frames placed on an IEEE network include two address-related ®elds: destination and source address. Each address normally represents a 6-byte address burnt into read-only memory (ROM) on the network adapter card of the frame
2.3 THE ISO REFERENCE MODEL Figure 2.3 Data ¯ow within an ISO Reference Model network 23
24 THE TCP/IP PROTOCOL SUITE originator (source address) and the frame recipient (destination address). The ®rst three bytes of the 6-byte network adapter card address are assigned by the IEEE to an adapter card manufacturer, and represent the manufacturer identi®cation (ID) portion of the address. The next three bytes are used by the adapter card manufacturer to uniquely identify each adapter card that it manufactures. If the manufacturer is so successful that it runs out of its allocated 3-byte sequence of numbers, it will request another manufacturer ID from the IEEE and use that ID for producing a new series of network adapter cards. Figure 2.4 illustrates the general format of an IEEE Mac address. When used as a source address, a bit composition of all binary 1s represents a broadcast address and results in each station copying the contents of the frame off the network. Depending upon the type of LAN, the setting of different bits within the 6-byte source MAC address can be used to identify different groups. Then, each workstation associated with the group identi®er would copy the frame off the network. If the frame's destination address is neither a broadcast nor a group address, it will only be copied off the network by the station whose adapter address matches the destination address in the frame. Universally vs. locally administered addresses Two types of addresses can be associated with stations on an IEEE network: universally administered and locally administered. When a burnt-in ROM address is used, it is referred to as a universally administered address, as it is uniquely assigned by the IEEE. In comparison, a second type of address results from the effort of a LAN administrator or network manager to override the universally administered address. This second type of MAC address results from the creation of a batch ®le statement being used to set a locally generated address that overrides the burnt-in ROM address. Because this address is developed locally, it is referred to as a locally administered address. Note that, regardless of the type of MAC address, it is a layer 2 address that is 48 bits in length. Because TCP/IP addresses are 32 bits in length (IPv4) and represent both a network address and a host address on a network, a translation process is required to associate a layer 3 IP address to a layer 2 MAC address. Later in this book we will examine the address resolution process that performs the required translation. 2.4 THE TCP/IP PROTOCOL SUITE In the previous section we have an overview of the functions of the seven layers in the ISO Reference Model to provide a frame of reference when examining the TCP/IP protocol suite. In actuality, TCP/IP represents one of the earliest developed layered protocol suites and preceded the development of the ISO's OSI Reference Model by approximately 20 years. Although it predates the OSI Reference Model, we can obtain an appreciation of the protocol suite by comparing it with that model.
2.4 THE TCP/IP PROTOCOL SUITE 25 Figure 2.4 The IEEE MAC address format 2.4.1 Comparison with the ISO Reference Model Similar to the ISO Reference Model, the TCP/IP protocol suite is subdivided into distinct layers, commencing at the network layer. Although the protocol suite does not include equivalents to the lower two layers of the ISO Reference Model, it does provide a mechanism to translate addressing from the network layer of the reference model to MAC addresses used by LANs at the lower portion of the data link layer. This enables the TCP/IP protocol suite to use the physical layer supported by different LANs. A second key difference between the ISO Reference Model and the TCP/IP protocol suite occurs at the top of the suite. TCP/IP applications can be considered to represent the equivalent of layers 5 through 7 of the OSI Reference Model. Based upon the preceding, Figure 2.5 provides a general comparison of the TCP/IP protocol suite with the ISO Reference Model. Note that, as previously mentioned, the TCP/IP protocol suite commences at the equivalent of layer 3 of the ISO Reference Model. Thus, the dashed lines surrounding Ethernet, Token-Ring, and FDDI layer 2 protocols and their physical layers indicate that they are not actually part of the TCP/IP protocol suite. Instead, the Address Resolution Protocol (ARP), which can be viewed as a facility of the Internet Protocol (IP), provides the translation mechanism that enables IP addressed packets to be correctly delivered to workstations that use MAC addresses. In fact, the TCP/IP protocol suite can also run over ATM, with a special type of address resolution used to resolve IP to ATM addresses. Thus, address resolution enables the TCP/IP protocol suite to be transported by other protocols and use the physical layer speci®ed by those protocols. Now that we have an appreciation for the general relationship between the TCP/IP protocol stack and the ISO's Open System Interconnection Reference Model, let's turn our attention to the actual layers of the protocol suite. The network layer The Internet Protocol (IP) represents the network layer protocol employed by the TCP/IP protocol suite. IP packets are formed by the addition of an IP header to the layer 4 protocol data entity, which is either the Transport Control Protocol (TCP) or the User Datagram Protocol (UDP). IP headers contain 32-bit source and destination addresses that are normally subdivided to denote a network address and host address on the
26 THE TCP/IP PROTOCOL SUITE Figure 2.5 Comparing the TCP/IP Protocol Suite with the ISO Reference Model network. In actuality, the host address is really an interface on the network, since a host can have multiple interfaces, with each having a distinct address. However, over the years the terms host address and interface address have been used synonymously Ð although this is not technically correct. In Chapter 3 we will examine the IP header in detail. ICMP The Internet Control Message Protocol (ICMP) represents a diagnostic testing and error reporting mechanism that enables devices to generate various types of status and error reporting messages. Two of the more popularly employed ICMP messages are the Echo Request and Echo Response packets generated by the Ping application. Although Figure 2.5 indicates that ICMP is a layer 3 protocol, from a technical perspective an ICMP message is formed by the addition of an IP header to an ICMP message with the Type ®eld within the IP header set to indicate it is transporting an ICMP message. When we examine IP in Chapter 3, we will also turn our attention to the Internet Message Protocol. The transport layer The designers of the TCP/IP protocol suite recognized that two different types of data delivery transport protocols would be required. This resulted in two transport protocols supported by the protocol suite. TCP TCP is a reliable, connection-oriented protocol used to transport appli- cations that require reliable delivery and for which actual data should not be
2.4 THE TCP/IP PROTOCOL SUITE 27 exchanged until a session is established. From Figure 2.5 you will note that FTP, Telnet, SMTP, and HT TP are transported by TCP. Because TCP is a connection-oriented protocol, this means that actual data will not be transferred until a connection is established. While this makes sense when you are transmitting a ®le or Web pages, it also delays actual data transfer. UDP A second transport protocol supported by the TCP/IP protocol suite is UDP. UDP represents a connectionless protocol that operates on a best e¡ort basis. This means that instead of waiting for con¢rmation that a destination is available, UDP will commence actual data transfer, leaving it to the application to determine if a response was received. Examples of applications that use UDP include SNMP, NFS, and BOOTP. The use of UDP and TCP results in the pre®x of an appropriate header to application data. When TCP is used as the transport layer protocol, the TCP header and application data are referred to as a TCP segment. When UDP is used as the transport layer protocol, the UDP header and application data transported by UDP is referred to as a UDP datagram. Port numbers BecauseTCP and UDP were designed to transport multiple types of application data between a source and the same or di¡erent destinations, a mechanism was needed to distinguish one type of application from another. This mechanism is obtained by port number ¢elds contained in TCP and UDP headers and explains how a Web server can also support FTP and other appli- cations. In Chapter 4 we will turn our attention to the composition of TCP/IP transport protocol headers and the use of di¡erent port numbers. 2.4.3 Application data delivery In concluding this chapter we will examine the use of TCP/IP and LAN headers to facilitate the delivery of application data from a host on one Figure 2.6 LAN delivery of TCP/IP application data
28 THE TCP/IP PROTOCOL SUITE network to a host on another network. Figure 2.6 illustrates the manner by which a LAN frame containing TCP/IP application data is formed. The LAN frame header uses a MAC destination address to direct the frame to a router. The router removes the LAN header and trailer and uses a Wide Area Network (WAN) protocol to transport the IP datagram. At the destination network another router receives the inbound packet, removes the WAN header and trailer, and encapsulates the IP datagram into a LAN frame for delivery to the appropriate IP address. However, since LAN frames use MAC addresses while TCP/IP applications use IP addresses, the router will either check its memory to determine if it previously discovered the MAC address associated with the destination IP address or use the Address Resolution Protocol (ARP) to discover the MAC address. Once the destination MAC address is known, the router can complete the formation of the LAN frame and transmit it onto the network for delivery to the appropriate device.
Managing TCP/IP Networks: Techniques, Tools and Security Considerations. Gilbert Held Copyright & 2000 John Wiley & Sons Ltd Print ISBN 0-471-80003-1 Online ISBN 0-470-84156-7 3 THE INTERNET PROTOCOL In this chapter we continue to acquire a foundation of knowledge concerning the TCP/IP protocol suite by focusing attention upon the network layer in the suite. The Internet Protocol (IP) represents both the network layer protocol in the TCP/IP protocol suite as well as the data delivery mechanism that enables packets to be routed from source to destination. We will ®rst examine the composition of the ®elds within the IP header. This will include a detailed examination of IP addressing, since many network- related problems can be traced to this area. Because Internet Control Message Protocol (ICMP) messages are transported via IP, we will also examine the ICMP in this chapter. Once this has been accomplished, we will conclude this chapter by turning our attention to the evolving replacement of the present version of the IP, IPv4. That replacement is IPv6, which is sometimes referred to as the next generation IP or IPng. 3.1 THE IPv4 HEADER As noted above, the current version of the IP is version 4. Therefore, we will commence our examination of the network layer of the TCP/IP protocol suite by turning our attention to the IPv4 header. The ®elds in the IPv4 header are illustrated in Figure 3.1. In examining that illustration note that the header contains a minimum of 20 octets of data. Also note that the width of each ®eld is shown in Figure 3.1 with respect to a 32-bit word. In this chapter and succeeding chapters we will use the term octet to reference the width of different header ®elds. The term octet was employed by standards organizations to explicitly reference 8 bits operated upon as an entity at a time when computers were manufactured with different numbers of bits per byte. To alleviate potential confusion when referencing a group of 8 bits, standards organizations turned to the term octet. Today essentially all computers use 8-bit bytes, and the terms byte and octet are commonly used synonymously. To obtain an appreciation for the functions performed by the
30 THE INTERNET PROTOCOL Figure 3.1 The IPv4 header IPv4 header, let us turn our attention to reviewing the functions of each of the ®elds in the header. 3.1.1 Vers ®eld The Vers ®eld consists of four bits that identify the version of the IP used to create the datagram. The current version of the IP is 4 and the next generation of the IP is assigned version number 6. As we will note later in this chapter, the Vers ®eld retains its meaning in both the IPv4 and IPv6 headers. 3.1.2 Hlen and Total Length ®elds The second and fourth ®elds in the IPv4 header indicate the length of the header and the total length of the datagram, respectively. The Hlen ®eld indicates the length of the IPv4 header in 32-bit words. In comparison, the Total Length ®eld indicates the total length of the datagram to include its header and higher layer information, such as a following TCP or UDP header and application data following either of those headers. Because the Total Length ®eld consists of 16 bits, an IP datagram can be up to 216, or 65 535 octets in length. 3.1.3 Type of Service ®eld The Type of Service (TOS) ®eld is 1 octet or 8 bits in length. The purpose of this ®eld is to denote the importance of the datagram (precedence), delay, throughput, and reliability requested by the originator. Figure 3.2 illustrates the assignment of bit positions within the TOS ®eld. Because the TOS ®eld provides a mechanism to de®ne priorities for the routing of IP datagrams, it would appear that the TOS ®eld could be used to provide a Quality of Service (QoS) for IP. Applications can set the appropriate values in the TOS ®eld to indicate the type of routing path they would like. For example, a ®le transfer would probably request normal delay, high throughput, and normal reliability. In comparison, a real time video
3.1 THE IPv4 HEADER 31 Figure 3.2 The Type of Service ®eld application would probably select low delay, high throughput, and high reliability. While this concept appears to provide a QoS, this is not the case, as it does not provide a mechanism to reserve bandwidth. For example, 10 stations, each requiring 512 Kbps, could all de®ne an immediate priority for ¯owing through a router connected on a T1 circuit operating at 1.544 Mbps. Another problem associated with the TOS ®eld is the fact that many routers ignore its settings. This is due to the fact that, to support the TOS ®eld, a router would have to construct and maintain multiple routing tables, which in the era of relatively slow processors when the Internet evolved was not an attractive option with router manufacturers. Thus, although this ®eld provides a precedence de®nition capability, its use on a public network can be limited. Recognizing this limitation, plans were being developed to reuse the TOS ®eld as a mechanism to differentiate services requested when a data stream enters a network. This action resulted in a proposal to rename the TOS byte as a Diff Service ®eld, and an RFC was being developed to de®ne its use when this book was written. 3.1.4 Identi®cation ®eld The Identi®cation ®eld is two octets or 16 bits in length. This ®eld is used to identify each fragmented datagram and is one of three ®elds that govern fragmentation. The other two ®elds that govern fragmentation are the Flags ®eld and the Fragmentation Offset ®eld. IP fragmentation results when data ¯ow between networks encounters different size maximum transmission units (MTUs). The MTU is commonly set when a device driver initializes an interface and represents the payload portion of a frame, i.e., the frame length less frame overhead. Most protocol stacks support MTUs up to 64KÀ1 octets (65 535). Another MTU is a per route MTU, which represents the MTU that can be used without causing fragmentation from source to destination. Per route MTUs are usually
32 THE INTERNET PROTOCOL Table 3.1 Flag ®eld bit values Bit 0: Reserved (set to 0) Bit 1: 0 = may fragment, 1 = don't fragment Bit 2: 0 = last fragment, 1 = more fragment(s) follow maintained as a value in a host's routing table and are set either by manual con®guration or via a discovery process. When a route has interfaces with different MTUs and a large datagram must be transferred via an interface with a smaller MTU, the routing entity will either fragment the packet or drop it. As we will note in the next section, if the DON'T_FRAGMENT bit is set in the ¯ag ®eld the router will drop the datagram. This will result in the router generating an ICMP `Destination Unreachable±Fragmentation Needed' message to the originator, which will cause the MTU discovery algorithm to select a smaller MTU for the path and subsequent transmissions. 3.1.5 Flags ®eld This 3-bit ®eld indicates how fragmentation will occur. Bit 0 is reserved and set to zero, while the values of bits 1 and 2 de®ne whether or not fragmentation can occur and if the present fragment is the last fragment or if one or more fragments follow. Table 3.1 lists the values associated with the three bits in the Flags ®eld. 3.1.6 Fragment Offset ®eld The third ®eld in the IPv4 header that is involved with fragmentation is the Fragment Offset ®eld. This ®eld is 13 bits in length and indicates where the fragment belongs in the complete message. The actual value placed in this ®eld is an integer that corresponds to a unit of 8 octets and provides an offset in 64-bit units. IP fragmentation places the burden of effort upon the receiving station and the routing entity. When a station receives an IP fragment, it must fully reassemble the complete IP datagram prior to being able to extract the TCP segment, resulting in a requirement for additional buffer memory and CPU processing power at the receiver. In doing so it use the values in the Fragment Offset ®eld in each datagram fragment to correctly reassemble the complete datagram. Because the dropping of any fragment in the original datagram requires the original datagram to be present, most vendor TCP/IP protocol stacks set the DON'T_FRAGMENT bit in the Flag ®eld. As mentioned above, setting that bit causes oversized IP datagrams to be dropped and results in an ICMP `Destination Unreachable±Fragmentation Needed' message trans- mitted to the originator. This action results in the MTU discovery algorithm selecting a smaller MTU for the path and using that MTU for subsequent transmissions.
3.1 THE IPv4 HEADER 33 3.1.7 Time-to-Live ®eld The Time-to-Live (TTL) ®eld is one octet in length. This ®eld contains a value that represents the maximum amount of time a datagram can live. The use of this ®eld prevents a mis-addressed or mis-routed datagram from endlessly wandering the Internet or a private IP network. The value placed in the TTL ®eld can represent router hops or seconds, with a maximum value for either being 255. Because an exact time is dif®cult to measure and requires synchronized clocks, this ®eld is primarily used as a hop count ®eld. That is, routers decrement the value in the ®eld each time a datagram ¯ows between networks. When the value of this ®eld reaches zero, the datagram is sent to the great bit bucket in the sky. The current recommended default time-to-live value for IP is 64. 3.1.8 Protocol ®eld The purpose of the Protocol ®eld is to identify the higher layer protocol being transported within an IP datagram. By examining the value of this ®eld, networking devices can determine if they have to look further into the datagram or should simply forward the datagram towards its destination. For example, a router that receives an IP datagram whose Protocol ®eld value is 6 and which indicates the higher layer protocol is TCP would simply forward the datagram towards its destination. The 8-bit positions in the Protocol ®eld enables up to 256 protocols to be uniquely de®ned. Table 3.2 lists the current assignment of Internet protocol numbers. Although TCP and UDP by far represent the vast majority of upper layer protocol transmission, other protocols can also be transported that govern the operation of networks, such as the Exterior Gateway Protocol (EGP) and Interior Gateway Protocol (IGP) that govern the interconnection of autonomous networks. In examining the entries in Table 3.2 note that a large block of numbers are currently unassigned. Also note that the evolving IPv6 uses a Next Header ®eld in place of the Protocol ®eld but uses the values contained in the table. 3.1.9 Checksum ®eld The tenth ®eld in the IPv4 header is the Checksum ®eld. This 16-bit or 2-octet ®eld protects the header and is also referred to as the Header Checksum ®eld. 3.1.10 Source and Destination address ®elds Both the Source and Destination address ®elds are 32 bits in length. Each ®eld contains an address that normally represents both a network address and a host address on the network. Because it is extremely important to understand IP addressing, this topic will be covered in detail in Section 3.2 below.
34 THE INTERNET PROTOCOL Table 3.2 Assigned Internet Protocol numbers Decimal Keyword Protocol 0 HOPOPT IPv6 Hop-by-Hop Option 1 ICMP Internet Control Message 2 IGMP Internet Group Management 3 GGP Gateway-to-Gateway 4 IP IP in IP (encapsulation) 5 ST Stream 6 TCP Transmission Control Protocol 7 CBT CBT 8 EGP Exterior Gateway Protocol 9 IGP any private interior gateway (used by Cisco for their IGRP) 10 BBN-RCC-MON BBN RCC Monitoring 11 NVP-II Network Voice Protocol Version 2 12 PUP PUP 13 ARGUS ARGUS 14 EMCON EMCON 15 XNET Cross Net Debugger 16 CHAOS Chaos 17 UDP User Datagram 18 MUX Multiplexing 19 DCN-MEAS DCN Measurement Subsystems 20 HMP Host Monitoring 21 PRM Packet Radio Measurement 22 XNS-IDP XEROX NS IDP 23 TRUNK-1 Trunk-1 24 TRUNK-2 Trunk-2 25 LEAF-1 Leaf-1 26 LEAF-2 Leaf-2 27 RDP Reliable Data Protocol 28 IRTP Internet Reliable Transaction 29 ISO-TP4 ISO Transport Protocol class 4 30 NETBLT Bulk Data Transfer Protocol 31 MFE-NSP MFE Network Services Protocol 32 MERIT-INP MERIT Internodal Protocol 33 SEP Sequential Exchange Protocol 34 3PC Third Party Connect Protocol 35 IDPR Inter-Domain Policy Routing Protocol 36 XTP XTP 37 DDP Datagram Delivery Protocol 38 IDPR-CMTP IDPR Control Message Transport Protocol 39 TP++ TP++ Transport Protocol 40 IL IL Transport Protocol 41 IPv6 Ipv6 42 SDRP Source Demand Routing Protocol 43 IPv6-Route Routing Header for IPv6 44 IPv6-Frag Fragment Header for IPv6 45 IDRP Inter-Domain Routing Protocol 46 RSVP Reservation Protocol (Continued )
3.1 THE IPv4 HEADER 35 Table 3.2 Assigned Internet Protocol numbers (Continued ) Decimal Keyword Protocol 47 GRE General Routing Encapsulation 48 MHRP Mobile Host Routing Protocol 49 BNA BNA 50 ESP Encap Security Payload for IPv6 51 AH Authentication Header for IPv6 52 I-NLSP Integrated Net Layer Security 53 SWIPE IP with Encryption 54 NARP NBMA Address Resolution Protocol 55 MOBILE IP Mobility 56 TLSP Transport Layer Security Protocol (using Kryptonet key management) 57 SKIP SKIP 58 IPv6-ICMP ICMP for IPv6 59 IPv6-NoNxt No Next Header for IPv6 60 IPv6-Opts Destination Options for IPv6 61 any host internal protocol 62 CFTP CFTP 63 any local network 64 SAT-EXPAK SATNET and Backroom EXPAK 65 KRYPTOLAN Kryptolan 66 RVD MIT Remote Virtual Disk Protocol 67 IPPC Internet Pluribus Packet Core 68 any distributed ®le system 69 SAT-MON SATNET Monitoring 70 VISA VISA Protocol 71 IPCV Internet Packet Core Utility 72 CPNX Computer Protocol Network Executive 73 CPHB computer Protocol Heart Beat 74 WSN Wang Span Network 75 PVP Packet Video Protocol 76 BR-SAT-MON Backroom SATNET Monitoring 77 SUN-ND SUN ND PROTOCOL±Temporary 78 WB-MON WIDEBAND Monitoring 79 WB-EXPAK WIDEBAND EXPAK 80 ISO-IP ISO Internet Protocol 81 VMTP VMTP 82 SECURE-VMTP SECURE-VMPT 83 VINES VINES 84 TTP TTP 85 NSFNET-IGP NSFNET-IGP 86 DGP Dissimilar Gateway Protocol 87 TCF TCF 88 EIGRP EIGRP 89 OSPFIGP OSPFIGP 90 Sprite-RPC Sprite RPC Protocol 91 LARP Locus Address Resolution Protocol 92 MTP Multicast Transport Protocol (Continued )
36 THE INTERNET PROTOCOL Table 3.2 Assigned Internet Protocol numbers (Continued ) Decimal Keyword Protocol 93 AX.25 AX.25 Frames 94 IPIP IP-within-IP Encapsulation Protocol 95 MICP Mobile Internetworking Control Protocol 96 SCC-SP Semaphore Communications Sec. Protocol 97 ETHERIP Ethernet-within-IP Encapsulation 98 ENCAP Encapsulation Header 99 any private encryption scheme 100 GMTP GMTP 101 IFMP Ipsilon Flow Management Protocol 102 PNNI PNNI over IP 103 PIM Protocol Independent Multicast 104 ARIS ARIS 105 SCPS SCPS 106 QNX QNX 107 A/N Active Networks 108 IPPCP IP Payload Compression Protocol 109 SNP Sitara Networks Protocol 110 Compaq-Peer Compaq Peer Protocol 111 IPX-in-IP IPX in IP 112 VRRP Virtual Router Redundancy Protocol 113 PGM PGM Reliable Transport protocol 114 any 0-hop protocol 115 L2TP Layer 2 Tunneling Protocol 116 DDX D-II Data Exchange (DDX) 117±254 Unassigned 255 Reserved 3.1.11 Options and Padding ®elds The IP includes a provision for adding optional header ®elds. Such ®elds are identi®ed by a value greater than zero in the ®eld. Table 3.3 indicates IP Option ®eld values based upon the manner by which the Option ®eld is subdivided. That subdivision includes a 1-bit copy ¯ag, a 2-bit class ®eld, and a 5-bit option number. The value column in Table 3.3 indicates the value of the 8-bit ®eld. IP options are commonly referred to by this value. Options whose values are 0 and 1 are exactly 1 octet long, which is their Type ®eld. All other options have their 1-octet Type ®eld followed by a 1-octet length ®eld followed by one or more octets of option data. The optional padding occurs when it becomes necessary to expand the header to fall on a 32-bit word boundary. 3.2 IP ADDRESSING IP addressing provides the mechanism that enables packets to be routed between networks as well as to be delivered to an appropriate host on a
3.2 IP ADDRESSING 37 Table 3.3 IP Option ®eld values Copy Class Number Value Name 0 0 0 0 EOOL: End of Options List 0 0 1 1 NOP: No Operation 1 0 2 130 SEC: Security 1 0 3 131 LSR: Loose Source Route 0 2 4 68 TS: Time Stamp 1 0 5 133 E-SEC: Extended Security 1 0 6 134 CIPSO: Commercial Security 0 0 7 7 RR: Record Route 1 0 8 136 SID: Stream ID 1 0 9 137 SSR: Strict Source Route 0 0 10 10 ZSU: Experimental Measurement 0 0 11 11 MTUP: MTU Probe 0 0 12 12 TRUR: MTU Reply 1 2 13 205 FINN: Experimental Flow Control 1 0 14 142 VISA: Experimental Access Control 0 0 15 15 ENCODE 1 0 16 144 IMITD: IMI Traf®c Descriptor 1 0 17 145 EIP: 0 2 18 82 TR: Traceroute 1 0 19 147 ADDEXT: Address Extension 1 0 20 148 RTRALT: Router Alert 1 0 21 149 SDB: Selective Directed Broadcast 1 0 22 150 NSAPA: NSAP Addresses destination network. As noted earlier in this chapter, there are two versions of the IP. The current version in IPv4, while the next generation IP, which is currently operated on an experimental portion of the Internet, is IPv6. Because there are signi®cant differences in the method of addressing used by each version of IP, we will cover both versions in this section. First, we will focus our attention upon the 32-bit addressing scheme employed under IPv4. Once we have obtained an appreciation for the manner by which IPv4 addresses are formed and used, we will then turn our attention to IPv6. 3.2.1 Overview IPv4 uses 32-bit IP addresses to identify distinct device interfaces, such as interfaces that connect routers, workstations, and gateways to networks, as well as to route data to those devices. Each device interface in an IP network must be assigned a unique IP address to enable it to receive communications addressed to the interface. Normally workstations have a single interface in the form of a LAN connection, which would be assigned an IP address. However, routers typically have more than one interface, and some high performance servers may have two network connections. In such instances each device interface would have a separate IP address.