2.5. IP

IP provides a connectionless, unreliable datagram delivery service. Connectionless means that the transmission of each datagram is a distinct event, and no state is maintained by the host about previously sent datagrams. Unreliable means that IP makes no guarantees about whether the datagram will be delivered and, if it is, whether it will be delivered in order with respect to other datagrams.

The standard analogy is that IP is like sending a letter or postcard. We separately address each letter that we send, even if it is going to the same correspondent as our last letter. The post office handles our letters without regard to any other letters we may have sent to the same correspondent; that is, it does not maintain state between letters. Nor does the post office guarantee that our letters will not be lost, delayed, or delivered out of order.

Note that we are talking about IP here. It may be that the application or transport layer is maintaining state and providing reliability. The point is that IP isn't doing so.

Given that IP provides such a bare-bones service, we might ask why we bother with it at all. Why not merely define a reliable service in the first place? The answer is that IP provides a simple building block upon which other, more robust, protocols can be built.

When viewed from abovefrom the upper layers in the stackIP provides a simple packet-transport vehicle that makes no assumptions about the packets it will be carrying. The upper layers simply load the data and tell IP where to deliver it. IP does not care about or look at the data it is carrying. This means that IP is capable of serving as a delivery mechanism for a wide variety of upper-level protocols.

The view from belowfrom the physical medium on which IP runsis of a very undemanding protocol. Because it assumes nothing about the underlying medium except that it is capable of routing packets, IP can run on any type of physical network that can carry packets. Thus, IP can, and does, run on a wide variety of physical networks. A few of the (widely different) physical networks that IP runs on are serial lines, Ethernet, Token Ring, asynchronous transfer mode (ATM) WANs, X.25, FDDI, cellular digital packet data (CDPD), and 802.11 WiFi. There are many others. The fact that IP runs on all these physical networks means that the upper-layer protocols, such as UDP and TCP, do too. We see, therefore, that the simplicity of IP is its chief strength. The IP specification is given in RFC 791 [Postel 1981a].

The IP Header

Figure 2.11 shows the format of the IP header. This is the header for version 4 of IP. See Figure 2.37 for the version 6 header format. The length of the header in 32-bit words is given in the hdr. len. field. For the normal case, in which the IP header contains no options, this will be a 5.

Figure 2.11. The IPv4 Header

[View full size image]

The type of service field contains either a precedence value and bit field specifying how routers should handle the datagram, or it contains explicit congestion notification (ECN) information.

The total length field is the length in bytes of the complete datagram, including the headers. This field is 16 bits, so the maximum sized IP datagram is 65,535 bytes.

Even though an IP datagram can be up to 65,535 bytes, most physical networks can't handle packets that large. Ethernet, for example, has a maximum payload, called the maximum transmission unit (MTU), of 1,500 bytes. If an application tries to send a datagram larger than the MTU of the interface, IP breaks the datagram into smaller fragments. Even if the datagram is smaller than the MTU of the sending host's interface, it may encounter a smaller MTU at one of the intermediate hops, causing the router to fragment the datagram.

If a datagram is fragmented, the total length field will contain the size of the fragment, and the fragment offset field will contain the offset of the fragment in the original datagram. Every fragment except the last will have the more fragments (MF) bit set. The fragments of an IP datagram are tied together with the identification field. Every IP datagram that a host sends will have a unique (modulo 2¹⁶) identification number, so even if the datagram is fragmented by an intermediate router, the destination host will have the required information to reassemble the datagram. Hosts can signal routers not to fragment a datagram by setting the don't fragment (DF) bit. This bit is useful for discovering the minimum MTU on the path from source to destination in a process called path MTU (PMTU) discovery. The PMTU discovery process is described in RFC 1191 [Mogul and Deering 1990].

To prevent IP datagrams from circulating in the Internet indefinitelybecause of a router loop, sayeach datagram carries a time to live (TTL) value. The sending host initializes the TTL to some value (typically 32 or 64), and the router at every hop decrements it by 1. If the TTL reaches 0 before it arrives at its destination, the datagram is dropped, and an error message is sent back to the source host, using ICMP.

IP datagrams are used to carry upper-layer protocols and, sometimes, network-layer protocols, such as ICMP. The type of protocol that the datagram is carrying is in the protocol field. Some important protocols and their values are shown in Figure 2.12.

Figure 2.12. Internet Protocols

Protocol	Value	Description
ICMP	1	Internet Control Message Protocol
IGMP	2	Internet Group Management Protocol
IP/IP	4	IP-in-IP
TCP	6	Transmission Control Protocol
UDP	17	User Datagram Protocol
IPv6	41	IP version 6
GRE	47	Generic Routing Encapsulation
ESP	50	Encapsulating Security Payload
AH	51	Authentication Header
OSPF	89	Open Shortest Path First Routing Protocol
L2TP	115	Layer Two Tunneling Protocol

The fields in the IP header are protected by the standard Internet checksumsee RFC 1071 [Braden, Borman, and Partridge 1988]. After the header is completely filled in, IP calculates the checksum and places it in the IP header checksum field. Note that the IP header checksum covers only the header itself, not the data that the datagram carries. This means that the upper-layer protocols must provide their own checksums if they require one.

The source address and destination address fields hold the 32-bit source and destination IP addresses. We discussed IP addresses in Section 2.4.

Looking at lines 1.1 and 1.2 from Figure 2.4, we see the IP header encapsulating the upper-layer protocols:

1.1       4500 0049 007c 4000 4006 e1e9 ac1e 000c   E..I.|@.@.......
1.2       ac1e 0001 0403 1388 445d 9b9b 53ff 98e7   ........D]..S...

The 45 in the first byte tells us that this is an IPv4 datagram (first 4 bits) with a header size of 20 bytes (second 4 bits). The third and fourth bytes tell us that the entire datagram is 73 (0x49) bytes. We see from the ninth byte that the operating system (FreeBSD, in this case) has set the initial TTL to 64 (0x40). The next byte tells us that the datagram is encapsulating protocol 6. From Figure 2.12, we see that this is TCP. Finally, we see that the sending host's IP address is 172.30.0.12 (0xac1e000c), and that it is sending the datagram to 172.30.0.1 (0xac1e0001).