The Ip in Tcp/Ip

52-20-30

DATA COMMUNICATIONS MANAGEMENT UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP

Gilbert Held

INSIDE The Internet Protocol; Datagrams and Segments; Datagrams and Datagram Transmission; Routing; The IP Header

INTRODUCTION This two-part article focuses on the first layer of the TCP/IP protocol suite. While the Internet Protocol (IP) is the primary protocol most peo- ple associate with the network layer, there are two related protocols that must be considered when discussing the TCP/IP protocol suite. Those protocols are the Address Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP). This article focuses on what this author commonly refers to as the Net- work Layer Troika of the TCP/IP protocol suite: IP, ARP, and ICMP. In examining the Internet Protocol, particular attention is paid to the structure of the IP header and its fields, which are examined by routers as a mechanism for making forwarding decisions. A second related article (52-20-31) focuses on another specific IP area, addressing, as the composition of IP addresses determines how data- PAYOFF IDEA grams are routed from source to des- The Internet Protocol (IP) represents the network tination, as well as the number of layer of the TCP/IP protocol suite. It was devel- hosts that can be connected to a spe- oped as a mechanism to interconnect packet- cific type of network. The second ar- switched TCP/IP networks. Since the initial development of TCP/IP, its modular architecture has ticle examines IP addressing in terms enabled literally hundreds of applications to be of several little-known areas of IP developed that use the protocol suite as a trans- that, having knowledge about, can port for communications. By developing an un- provide network design and opera- derstanding of these important technologies, the network manager will be better positioned to tion flexibility. Two examples of make effective decisions regarding the ongoing such topics are the assignment of support and evolution of networks under his or her purview.

DATA COMMUNICATIONS MANAGEMENT multiple network addresses to an interface and the use of a zero subnet. The filtering of IP datagrams by routers and firewalls can occur, based on IP addresses, as well as ICMP message types and control field values. The initial focus in this article is on IP, to include its use for routing datagrams across a network and between interconnected networks. In doing so, the author examines, in detail, the composition of the IP header and the use of different fields in the header. Once accomplished, attention is directed to the role and operation of the Address Resolution Protocol (ARP), which includes examining the ra- tionale for a little-known ARP technique that can considerably facilitate the operation of delay-sensitive transmissions such as Voice over IP. In concluding the second article (52-20-31), the author focuses on the Inter- net Control Message Protocol (ICMP).

THE INTERNET PROTOCOL The Internet Protocol (IP) represents the network layer of the TCP/IP protocol suite. IP was developed as a mechanism to interconnect packet- switched TCP/IP-based networks to form an internet. Here, the term “internet” with a lowercase “i” is used to represent the connection of two or more TCP/IP-based networks.

Datagrams and Segments IP transmits blocks of data referred to as datagrams, and receives upper layer protocol data containing either a TCP or UDP header, referred to as a TCP segment or UDP datagram. The preﬁx of an IP header to the TCP segment or UDP datagram results in the formation of an IP datagram. This datagram contains a destination IP address that is used for routing purposes.

Datagrams and Datagram Transmission To alleviate potential confusion between datagrams and an obsolete transmission method referred to as datagram transmission, a few words are in order. When the ARPAnet evolved, it experimented with two meth- ods of packet transmission. One method was referred to as datagram transmission and avoided the use of routers to perform table lookups. Under datagram transmission, each node in a network transmits a received datagram onto all ports other than the port on which the datagram was received. While this technique avoids the need for routing table lookup operations, it can result in duplicate datagrams being received at certain points within a network. This results in the necessity to develop software to discard duplicate datagrams, adding an additional level of complexity to networking. Thus, datagram transmission was soon discarded in favor of the creation of virtual circuits that represent a tempo-

UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP rary path established between source and destination. As such, datagram transmission will actually be referencing the transmission of datagrams via a virtual circuit created between source and destination.

Routing The actual routing of an IP datagram occurs on a best-effort or connec- tionless delivery mechanism. This is because IP by itself does not estab- lish a session between the source and destination before it transports datagrams. When IP transports a TCP segment, the TCP header results in a connection-oriented session between two Layer 4 nodes transported by IP as a Layer 3 network protocol. The importance of IP can be noted by the fact that routing between networks is based on IP addresses. As discussed later in this article, the device that routes data between different IP addressed networks is known as a router. Because it would be extremely difficult — if not im- possible — to statically configure every router in a large network to know the route to other routers and networks connected to different routers, routing protocols are indispensable to the operation of a dynam- ic series of interconnected IP networks. The best way to obtain an appreciation for the operation of IP is through an examination of the fields in its header.

The IP Header The current version of IP is version 4, resulting in IP commonly referred to as IPv4. The next generation of IP is IPv6. This section focuses attention on IPv4. Exhibit 1 illustrates the ﬁelds contained in the IPv4 header. In examining this header, note that the header consists of a minimum of 20 bytes of data, with the width of each ﬁeld shown with respect to a 32-bit (4-byte) word.

Bytes versus Octets. In this article, the term “byte” refers to a sequence of eight bits used in a common manner. During the development of the TCP/IP protocol suite and continuing today, most standards documents use the term “octet” to reference a collection of eight bits. The use of the term “octet” is due to differences in the composition of a byte during the 1960s. During the early development of computer systems, differences in computer architecture resulted in the use of groupings of ﬁve to ten bits to represent a computer byte. Thus, the term “byte” at that time was ambiguous, and standards-making bodies decided to use the term “octet” to reference a grouping of 8 bits. Because all modern computers use 8-bit bytes, the term “byte” is no longer ambiguous. Thus, the term “byte” is used throughout this article as well as (52-20-31).

DATA COMMUNICATIONS MANAGEMENT

EXHIBIT 1 — The Ipv4 Header

To obtain an appreciation for the operation of IP, one can examine the functions of the ﬁelds in the header. In doing so, and when appropriate, relation of certain ﬁelds to routing and security is discussed.

Vers Field. The Vers ﬁeld is four bits in length and is used to identify the version of IP used to create an IP datagram. The current version of IP is v4, with the next generation of IP assigned as version 6 (v6). The four bits in the Vers ﬁeld support 16 version numbers. Under RFC 1700, a listing of Internet version numbers can be obtained and a sum- mary of that listing is included in Exhibit 2. In examining Exhibit 2, note that the reason the next-generation Internet Protocol is IPv6, instead of IPv5, relates to the fact that Version 5 was previously assigned to an ex- perimental protocol referred to as the Streams 2 Protocol.

Hlen Field. The length of the IP header can vary due to its ability to support options. To allow a receiving device to correctly interpret the contents of the header from the remainder of an IP datagram requires the receiving device to know where the header ends. This function is per- formed by the Hlen field, the value of which indicates the length of the header. The Hlen field is four bits in length. In examining Exhibit 1, note that the IP header consists of 20 bytes of fixed information followed by options. Because it is not possible to use a four-bit field to directly indicate the length of a header equal to or exceeding 320 bytes, the value in this field represents the number of 32-bit words in the header. As an example, the shortest IP header is 20 bytes, which represents 160 bits. When divided by 32 bits, this results in a value of 160/32 (or 5), which is the value set into the Hlen field when the IP header contains 20 bytes and no options.

UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP

EXHIBIT 2 — Assigned Internet Version Numbers

Numbers Assignment

0 Reserved 1–3 Unassigned 4IP 5 Streams 6 IPv6 7 TP/IX 8 P Internet Protocol (PIP) 9 TUBA 10–14 Unassigned 15 Reserved

Service Type Field. The Service Type field is an 8-bit field commonly referred to as a Type of Service (ToS) field. The initial development of IP assumed that applications would use this field to indicate the type of routing path they would like. Routers along the path of a datagram would examine the contents of the Service Type byte and attempt to comply with the setting in this field. Exhibit 3 illustrates the format of the Service field. This field consists of two sub-fields: Type of Service (ToS) and Precedence. The Type-of- Service sub-field consists of bit positions that, when set, indicate how a datagram should be handled. The three bits in the Precedence sub-field allow the transmitting station to indicate to the IP layer the priority for sending a datagram. A value of 000 indicates a normal precedence, while a value of 111 indicates the highest level of precedence and is normally used for network control. The value in the Precedence field is combined with a setting in the ToS field to indicate how a datagram should be processed. As indicated in the lower portion of Exhibit 3, there are six settings defined for the ToS field. To understand how this field be used, assume that an application is transmitting digitized voice that requires minimal routing delays due to the effect of latency on the reconstruction of digitized voice. By setting the ToS field to a value of 1000, this would indicate to each router in the path between source and destination network that the datagram is delay sensitive and its processing by the router should minimize delay. In comparison, because routers are designed to discard packets under periods of congestion, an application in which the ability of packets to reach their destination is of primary importance would set the ToS sub- field to a value of 0010. This setting would denote to routers in the transmission path that the datagram requires maximum reliability. Thus, routers would select other packets for discard prior to discarding a packet with its ToS sub-field set to a value of 0010.

DATA COMMUNICATIONS MANAGEMENT

EXHIBIT 3 — The Service Type Field

Although the concept behind including a Service Type field was a good idea, from a practical standpoint it is rarely used. The reason for its lack of use is the need for routers supporting this field to construct and maintain multiple routing tables. While this is not a problem for small networks, the creation and support of multiple routing tables can signif- icantly affect the level of performance of routers in a complex network such as the Internet. Although routers in most networks ignore the contents of the Service Type field, this field is now being used to map IP datagrams being transmitted over an ATM backbone. Because ATM includes a built-in Quality of Service (QoS) that, at the present time, cannot be obtained on an IP network, many organizations are transmitting a variety of data to include voice-over-IP over an ATM backbone, using the Service Type field as a mechanism to map different IP service requirements into applicable types of ATM service. A second emerging application for the Service Type field is to differentiate the requirements of the various applications as they flow into an IP network. In this situation, the Service Type byte is renamed as the DiffServe (Differentiated Service) byte. The Internet Engineering Task Force is currently examining the potential use of the

UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP

DiffServe byte as a mechanism to deﬁne an end-to-end QoS capability through an IP network.

Total Length Field. The Total Length field indicates the total length of an IP datagram in bytes. This length indicates the length of the IP header, to include options, followed by a TCP or UDP header (or another type of header discussed below), as well as the data that follows that header. The Total Length field is 16 bits in length, resulting in an IP datagam having a maximum defined length of 2 ¥ 1016 (or 65,535) bytes.

Identification and Fragment Offset Fields. Unlike some types of clothing where one size fits all, an IP datagram can range up to 65,535 bytes in length. Because some networks only support a transport frame that can carry a small portion of the theoretical maximum-length IP datagram, it may become necessary to fragment the datagram for transmission between networks. One example of this would be the routing of a datagram from a Token Ring network to another Token Ring network via an Ethernet network. Token Ring networks that operate at 16 Mbps can transport approximately 18 Kbytes in their Information field. In comparison, an Ethernet frame has a maximum-length Information field of 1500 bytes. This means that datagrams routed between Token Ring networks via an Ethernet network must be subdivided, or fragmented, into a maximum length of 1500 bytes for Ethernet to be able to transport the data. The default IP datagram length is referred to as the path MTU (Maxi- mum Transmission Unit). The MTU is defined as the size of the largest packet that can be transmitted or received through a logical interface. For the previous example of two Token Ring networks connected via an Ethernet network, the MTU would be 1500 bytes. Because it is important to commence transmission with the lowest common denominator packet size that can flow through different networks, and, if possible, adjust the packet size after the initial packet reaches its destination, IP datagrams use a default of 576 bytes when datagrams are transmitted remotely (off the current network). Fragmentation is a most interesting function because it allows networks capable of transmitting larger packets to do so more efficiently. The reason efficiency increases is due to the fact that larger packets have proportionally less overhead. Unfortunately, the gain in packet efficiency is not without cost. First, although routers can fragment datagrams, they do not reassemble them, leaving it to the host to perform reassembly. This is because router CPU and memory requirements would considerably expand if they had to reassemble datagrams flowing to networks containing hundreds or thousands of hosts. Second, although fragmentation is a good idea for boosting transmission efficiency, a setting in the Flag field (see below) can be used to indicate that a datagram should not be fragmented. Because many routers do not support fragmentation,

DATA COMMUNICATIONS MANAGEMENT many applications, by default, set the Do Not Fragment Flag bit and use a datagram length that, while perhaps not most efficient, ensures that a datagram can flow end-to-end because its length represents the lowest common denominator of the networks it will traverse. When an IP datagram is fragmented, this situation results in the use of three fields in the IP header: Identification, Flags, and Fragment Offset. The Identification field is 16 bytes in length and is used to indicate which datagram fragments belong together. A receiving device operation at the IP network layer uses the Identification field as well as the source IP address to determine which fragments belong together. To ensure fragments are put back together in their appropriate order requires a mechanism to distinguish one fragment from another. That mechanism is provided by the Fragment Offset field, which indicates the location where each fragment belongs in a complete message. The actual value in the Fragment Offset field is an integer that corresponds to a unit of 8 bytes, which indicates the offset from the previous datagram. For example, if the first fragment is 512 bytes in length, the second fragment would have an offset value that indicates that this IP datagram commenc- es at byte 513. Using the Total Length and Fragment Offset fields, a receiver can easily reconstruct a fragmented datagram.

Flag Field. The third field in the IP header directly associated with fragmentation is the Flag field. This field is four bytes in length, with two bits used to denote fragmentation information. The setting of one of those bits is used as a direct fragment control mechanism, because a value of “0” indicates the datagram can be fragmented, while a value of “1” indicates do not fragment the datagram. The second fragment bit is used to indicate fragmentation progress. When the second bit is set to a value of “0,” it indicates that the current fragment in a datagram is the last fragment. In comparison, a value of “1” in this bit position indicates that more fragments follow.

Time to Live Field. The Time to Live (TTL) field is eight bits in length. The setting in this field is used to specify the maximum amount of time that a datagram can exist. It is used to prevent a mis-addressed datagram from endlessly wandering the Internet or a private IP network, similar to the manner by which a famous American folk hero was noted in a song to wander the streets of Boston. Because an exact time is difficult to measure, the value placed into the TTL field is actually a router hop count. That is, routers decrement the value of the TTL field by 1 as a datagram flows between networks. If the value of this field reaches zero, the router will discard the datagram, and depending on the configuration of the router, generate an ICMP message that informs the originator of the datagram that the TTL field expired and the datagram, in effect, was sent to the great bit bucket in the sky.

UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP

Many applications set the TTL field value to default of 32, which should be more than sufficient to reach most destinations in a very complex network, to include the Internet. In fact, one popular application referred to as traceroute will issue a sequence of datagrams commencing with a value of 1 in the TTL field to obtain a sequence of router-generated ICMP messages that enables the path from source to destination to be noted.

Protocol Field. An IP header prefixes the transport layer header to form an IP datagram. While TCP and UDP represent a large majority of Layer 4 protocols carried in an IP datagram, they are not the only protocols transported. In addition, even if they were, one would need a mechanism to distinguish one upper layer protocol from another that is carried in a datagram. The method used to distinguish the upper layer protocol carried in an IP datagram is obtained through the use of a value in the Protocol field. For example, a value of decimal 6 is used to indicate that a TCP header follows the IP header, while a value of decimal 17 indicates that a UDP header follows the IP header in a datagram. The Protocol field is eight bits in length, permitting up to 256 protocols to be defined under IPv4. Exhibit 4 lists the current assignments of Internet protocol numbers. Note that although TCP and UDP by far represent the vast majority of TCP/IP traffic on the Internet and corporate in- tranets, other protocols can be transported and a large block of protocol numbers are currently unassigned. Also note that under IPv6, the protocol field is named the Next Header field.

Header Checksum Field. The Header Checksum field contains a 16- bit cyclic redundancy check (CRC) character. The CRC represents a number generated by treating the data in the IP header field as a long binary number and dividing that number by a fixed polynomial. The result of this operation is a quotient and remainder, with the remainder being placed into the 16-bit Checksum field by the transmitting device. When a receiving station reads the header, it also performs a CRC operation on the received data, using the same fixed polynomial. If the computed CRC does not match the value of the CRC in the Header Checksum field, the receiver assumes the header is in error and the packet is discarded. Thus, the Header Checksum field, as its name implies, provides a mechanism for ensuring the integrity of the IP header.

Source and Destination Address Fields. Both the Source and Desti- nation Address ﬁelds are 32 bits in length under IPv4. The Source Ad- dress represents the originator of the datagram, while the Destination Address represents the recipient.

DATA COMMUNICATIONS MANAGEMENT

EXHIBIT 4 — 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

UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP

EXHIBIT 4 — 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 93 AX.25 AX.25 Frames

DATA COMMUNICATIONS MANAGEMENT

EXHIBIT 4 — Assigned Internet Protocol Numbers (Continued)

Decimal Keyword Protocol

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

Under IPv4, there are ﬁve classes of IP addresses, referred to as Class A through Class E. Classes A, B, and C are subdivided into a network portion and a host portion and represent addresses used on the Internet and private IP-based networks. Classes D and E represent two special types of IPv4 network addresses. Because it is extremely important to understand the composition and formation of IP addresses to correctly conﬁg- ure devices connected to an IP network, as well as to design and modify such networks, the next article (52-20-31) focuses on this topic. Given an appreciation of IP addressing, one can then examine the use of the Ad- dress Resolution Protocol (ARP), noting how it is used to enable Layer 3 IP datagrams that use 32-bit IP addresses to be correctly delivered by LANs using 48-bit Layer 2 MAC addresses.

Additional Reading Gilbert Held, “Working with TCP/IP Utilities,” Data Communications Management, June 1999 (51-10-99). Gilbert Held, “Understanding IP Addressing,” Data Communications Management, April 2000 (52-20-31). Gurugé, Anura, “Gracefully Transitioning from SNA to IP,” Data Communications Management, June 1999 (51-10-95).

UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP

Gilbert Held is an award-winning author and lecturer. Gil is the author of over 40 books and 400 technical articles covering personal computers and computer communications. Some of Gil’s recent titles include Cisco Access Lists, Cisco Router Performances, and Data over Wireless Networks (McGraw-Hill). Among his many books and articles, Gil is the author of TCP/IP Professional Reference Guide (Auerbach Publications, ©2000, ISBN 0-8493- 0824-0), from which this article is extracted. Gil can be reached via e-mail at [email protected].