a ddrESSIng at l ayErS 2 and 3 and thE
3.5 The IPv4 Header
As noted at the beginning of this chapter, the current version of the Internet Protocol is version 4. Thus we will commence our exami-nation of the network layer of the TCP/IP protocol suite by turn-ing our attention to the IPv4 header, to include becomturn-ing familiar with IPv4 addressing. The fields in the IPv4 header are illustrated in Figure 3.12. Note that the header contains a minimum of 20 octets of data. Also note that the width of each field is shown in Figure 3.12 with respect to a 32-bit word.
3.5.1 Vers Field
The Vers field consists of 4 bits that identify the version of the IP protocol used to create the datagram. The current version of the IP protocol is 4, and the next generation of the IP protocol is assigned version number 6. As we will note later the Vers field retains its mean-ing in both the IPv4 and IPv6 headers. Table 3.2 lists the assignment of numbers to the Version field.
3.5.2 Hlen and Total Length Fields
The second and fourth fields in the IPv4 header indicate the length of the header and the total length of the datagram, respectively. The Hlen field indicates the length of the IPv4 header in 32-bit words. In
Figure 3.12 The IPv4 header.
comparison, the Total Length field 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 field consists of 16 bits, an IP datagram can be up to 216, or 65,535 octets in length.
3.5.3 Type of Service Field The Type of Service (TOS) field is one octet or 8 bits in length. The purpose of this field is to denote the importance of the datagram (precedence), delay, throughput, and reli-ability requested by the originator.
Figure 3.13 illustrates the assignment of bit positions within the TOS field. Because the TOS field provides a mechanism to define priorities for the routing of IP datagrams, the TOS field could be used to provide a quality of service (QoS) for IP. Applications can set the appropriate values in the TOS field to indicate the type of
Figure 3.13 The Type of Service field.
Table 3.2 Assigned Internet Version Numbers
NUMBERS ASSIGNMENT
0 Reserved
1–3 Unassigned
4 IP
5 Streams
6 IPv6
7 TP/IX
8 P Internet Protocol (PIP)
9 TUBA
10–14 Unassigned
15 Reserved
routing path they would like. For example, a file transfer would prob-ably request normal delay, high throughput, and normal reliability.
In comparison, a real-time video 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 define an immediate priority for flowing through a router connected on a T1 circuit operating at 1.544 Mbps.
Another problem associated with the TOS field is that many routers ignore its settings. This is due to the fact that to support the TOS field 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 field provides precedence definition capability, its use on a public network can be limited. Recognizing this limitation, plans were developed to reuse the TOS field 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 field, and an RFC was developed to define its use.
3.5.4 Identification Field
The Identification field is two octets or 16 bits in length. This field is used to identify each fragmented datagram and is one of three fields that govern fragmentation. The other two fields that govern fragmen-tation are the Flags field and the Fragmenfragmen-tation Offset field.
IP fragmentation results when data flow between networks encoun-ters different size 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 64,000 – 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 maintained as a value in a host’s routing table and set either by manual configuration 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 note in the next
section, if the DON’T_FRAGMENT bit is set in the Flags field, the router will drop the datagram. This will result in the router generating an ICMP “Destination Unreachable—Fragmentation Needed” mes-sage to the originator, which will cause the MTU discovery algorithm to select a smaller MTU for the path and subsequent transmissions.
3.5.5 Flags Field
This 3-bit field indicates how fragmentation will occur. Bit 0 is reserved and set to zero, while the values of bits 1 and 2 define whether or not fragmentation can occur and if the present fragment is the last frag-ment or one or more fragfrag-ments follow. Table 3.3 lists the values asso-ciated with the 3 bits in the Flags field.
3.5.6 Fragment Offset Field
The third field in the IPv4 header that is involved with fragmenta-tion is the Fragment Offset field. It is 13 bits in length and indicates where the fragment belongs in the complete message. The actual value placed in this field is an integer that corresponds to a unit of eight octets and provides an offset in 64-bit units.
IP fragmentation places the burden of effort upon the receiving sta-tion and the routing entity. When a stasta-tion 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 uses the values in the Fragment Offset field 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 re-sent, most vendor TCP/IP protocol stacks set the DON’T_FRAGMENT bit in the Flags field. Setting that bit causes oversized IP datagrams to be dropped and results in an ICMP “Destination Unreachable—Fragmentation Needed” message
Table 3.3 Flag Field Values Bit 0 Reserved (set to 0)
Bit 1 0 = may fragment, 1 = don’t fragment Bit 2 0 = last fragment, 1 = more fragments follow
transmitted to the originator. This action results in the MTU discov-ery algorithm selecting a smaller MTU for the path and using that MTU for subsequent transmissions.
3.5.7 Time to Live Field
The Time to Live (TTL) field is one 8-bit byte or octet in length. This field contains a value that represents the maximum amount of time a datagram can live. The use of this field prevents a misaddressed or misrouted datagram from endlessly wandering the Internet or a pri-vate IP network.
The value placed in the Time to Live field can represent router hops or seconds, with a maximum value for either being 255. Because an exact time is difficult to measure and requires synchronized clocks, this field is primarily used as a hop count field. That is, routers decre-ment the value in the field each time a datagram flows between net-works. When the value of this field 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.5.8 Protocol Field
The purpose of the Protocol field is to identify the higher-layer protocol being transported within an IP datagram. By examining the value of this field, networking devices can determine if they have to look further into the datagram or should simply forward the datagram toward its destination. For example, a router that receives an IP datagram whose Protocol field value is 6 and which indicates the higher-layer protocol is TCP would simply forward the datagram toward its destination.
The 8-bit positions in the Protocol field enable up to 256 protocols to be uniquely defined. Table 3.4 lists the assignment of IP Protocol field values. Although TCP and UDP by far represent the vast majority of upper-layer protocol transmission, other protocols can also be trans-ported 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 addition, a large block of numbers is currently unassigned. In comparison, IPv6
Table 3.4 Assigned Internet Protocol Numbers
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 its IGRP)
10 BBN-RCC-MON BBN RCC Monitoring
11 NVP-II Network Voice Protocol version 2
12 PUP PUP
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 Interdomain Policy Routing Protocol
36 XTP XTP
37 DDP Datagram Delivery Protocol
38 IDPR-CMTP IDPR Control Message Transport Protocol
39 TP++ TP++ Transport Protocol
(continued)
Table 3.4 Assigned Internet Protocol Numbers (continued)
DECIMAL KEYWORD 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 Interdomain Routing Protocol
46 RSVP Reservation Protocol
47 GRE General Routing Encapsulation
48 MHRP Mobile Host Routing Protocol
49 BNA BNA
50 ESP Encapsulating 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 file 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
Table 3.4 Assigned Internet Protocol Numbers (continued)
91 LARP Locus Address Resolution Protocol
92 MTP Multicast Transport 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 Security 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
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
uses a Next Header field in place of the Protocol field, but uses the values contained in Table 3.4.
3.5.9 Checksum Field
The tenth field in the IPv4 header is the Checksum field. This 16-bit or two-octet field protects the header and is also referred to as the Header Checksum field.
3.5.10 Source and Destination Address Fields
Both the Source and Destination Address fields are 32 bits in length.
Each field 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 we focus on this topic below.
3.5.11 Options and Padding Fields
Included in IPv4 is a provision for adding optional Header fields.
Such fields are identified by a value greater than zero in the field. IPv4 Option field values are based upon the manner by which the Option field is subdivided. That subdivision includes a 1-bit copy flag, a 2-bit Class field, and a 5-bit option number.
Options whose values are 0 and 1 are exactly one octet long, which is their Type field. All other options have their one-octet Type field followed by a one-octet Length field 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.