18.1. IP Protocol: The Big Picture

Figure 18-1 shows the important relationships among the components of Linux that handle IPv4. The flow of traffic between major functions is represented by arrows. We will analyze all of these functions in the next few chapters. The figure shows the placement of two subsystems described elsewherethe Neighboring subsystem and the Traffic Control subsystemas well as the many hooks where the Netfilter firewalling system can be invoked.^[*]

^[*] The functions used to handle multicast traffic are not included in Figure 18-1 (apart from ip_mc_output). The figure includes the main APIs; however, there are others that are used in specific cases. See Chapter 21.

Figure 18-1 is a useful reference when you're examining networking code and wondering whether a particular function is used for input or output, whether it is called during forwarding, and who calls it.

Since the IP layer does not interact directly with the Traffic Control subsystem, that subsystem is left to Part VI. However, in the section "Interface to the Neighboring Subsystem" in Chapter 21, we will see how IP and the Neighboring subsystem interact.

Figure 18-1. Core functions of the IP kernel stack

Among the tasks of the IP protocol are:

Sanity checks

IP datagrams could be discarded immediately upon entering the system, because of an incorrect checksum (that is, transmission has corrupted it), a header field out of range, or other reasons.

Firewalling

As shown in Figure 18-1, the Netfilter firewall subsystem (controlled on the user side by the iptables command) can be invoked at many points in the packet's history and can change its destiny. As we will see in Part V, Netfilter can be used at L2 as well.

Handling options

The IP protocol includes a few options that applications can use. Even though the original IP RFC (791) says the implementation of options is mandatory for both hosts and routers, not all of them are actually implemented. Some are universally recognized as obsolete, and others are used only in special cases.

Fragmentation/defragmentation

The len field of the IP header is long enough to allow datagrams up to 64 KB in size, but they almost never reach that limit. In fact, MTU values vary from one part of the network to another depending on the media used for transmission,^[*] so it is quite possible that a packet will be too big for one of the hops along the way. In such cases, the packet has to be split into smaller pieces to be successfully transmitted. Each fragment can be further fragmented before arriving at the destination, which must reassemble the fragments. The use of fragmentation is discouraged nowadays because it introduces problems. We will see them in the section "Packet Fragmentation/Defragmentation."

^[*] In Chapter 2, you can find a table with the MTU used by the most common interfaces.

Receive, transmit, and forward operations

Input packets are handled by reception functions, and output packets by transmission functions. Forwarding is related to transmission, but deals with packets received from other hosts instead of packets generated by higher network layers on the local system.

I briefly introduce the Raw IP protocol in Chapter 24 and IP-over-IP (also called IP tunneling) in Chapter 23.