Network Layer

The network access layer is still quite strongly influenced by the properties of the transmission medium and the device drivers of the associated adapters. The network layer (and therefore specifically the IP Internet protocol) is almost totally divorced from the hardware properties of the network adapters. Why only almost? As you will see shortly, the layer is responsible not only for sending and receiving data, but also for forwarding and routing packets between systems not directly connected with each other. Finding the best route and selecting a suitable network device to send the packet also involves handling lower-level address families (such as hardware-specific MAC addresses), which accounts for why the layer is at least loosely associated with network cards. The assignment between the addresses of the network layer and the network access layer is made in this layer — another reason why the IP layer is not fully divorced from the hardware.

Fragmentation of larger data packets into smaller units cannot be performed without taking the underlying hardware into account (in fact, the properties of the hardware are what make this necessary in the first place). Because each transmission technique supports a maximum packet size, the IP protocol must offer ways of splitting larger packets into smaller units that can be reassembled by the receiver — unnoticed by the higher layers. The size of the fragmented packets depends on the capabilities of the particular transmission protocol.

IP was formally defined in 1981 (in RFC 791) and is therefore of ripe old age.14 Even though the situation on the ground is not as represented in the usual company press releases that praise, for example, each new version of a spreadsheet as the greatest invention since the beginning of mankind, the last two decades have left their mark on today's technology. Deficiencies and unforeseen problems occasioned by the strong growth of the Internet are now more and more evident. This is why the IPv6 standard has been developed as the successor to the present IPv4. Unfortunately, this future standard is only slowly being adopted owing to the lack of a central control authority. In this chapter, our interest focuses on the implementation of the algorithms for Version 4, but we also take a cursory look at future practicable techniques and their implementation in the Linux kernel.

To understand how the IP protocol is implemented in the kernel, it is necessary to briefly examine how it works. Naturally, we can only touch on the relevant topics in this huge area. For detailed descriptions, see the many specialized publications, particularly [Ste00] and [Ste94].

12.8.1 IPv4

IP packets use a protocol header as shown in Figure 12-14.

0 4 8 16 20 24 32

Version

IHL

Codepoint/Type of service

Total length

Fragment Identification

Flags Fragment Offset

TTL

Protocol

Header Checksum

Source address

Destination address

Options

Padding

Payload

Figure 12-14: Structure of an IP header.

Figure 12-14: Structure of an IP header.

The meanings of the individual components of the structure are explained below.

14Even though the marketing departments of some companies suggest the opposite, the Internet is older than most of its users.

□ version specifies the IP protocol version used. Currently, this field accepts the value 4 or 6. On hosts that support both versions, the version used is indicated by the transmission protocol identifier discussed in the previous chapter; this identifier also holds different values for the two versions of the protocol.

□ ihl defines the header length, which is not always the same owing to the variable number of options.

□ Codepoint or Type of Service is required for more complex protocol options that need not concern us here.

□ Length specifies the total length of the packet, in other words, the length of the header plus data.

□ The fragment id identifies the individual parts of a fragmented IP packet. The fragmenting system assigns the same fragment ID to all parts of an original packet so that they can be identified as members of the same group. The relative arrangement of the parts is defined in the fragment offset field. The offset is specified in units of 64 bits.

□ Three status bits (flags) enable and disable specific characteristics; only two of them are used.

□ df stands for don't fragment and specifies that the packet must not be split into smaller units.

□ mf indicates that the present packet is a fragment of a larger packet and is followed by other fragments (the bit is set for all fragments but the last).

The third field is ''reserved for future use,'' which is very unlikely in view of the presence of IPv6.

□ ttl stands for Time to Live and specifies the number of intermediate stations (or hops) along the route to the receiver.15

□ Protocol identifies the higher-layer protocol (transport layer) carried in the IP datagram. For example, there are unique values for TCP and UDP.

□ Checksum contains a checksum calculated on the basis of the contents of the header and the data. If the specified checksum does not match the figure calculated upon receipt, the packet is discarded because a transmission error has occurred.

□ src and dest specify the 32-bit IP address of the source and destination.

□ options is used for extended IP options, not discussed here.

□ data holds the packet data (payload).

All numeric values in the IP header must be in network byte order (big endian). In the kernel sources the header is implemented in the iphdr data structure: <ip.h>

struct iphdr {

#if defined(_LITTLE_ENDIAN_BITFIELD)

#elif defined (_BIG_ENDIAN_BITFIELD)

_u8 version:4,

15In the past, this value was interpreted as the maximum lifetime in seconds.

frag_off; ttl;

protocol; check; saddr; daddr; options start here. */

The ip_rcv function is the point of entry into the network layer. The onward route of a packet through the kernel is illustrated in Figure 12-15.

Layers Linux

Figure 12-15: Route of a packet through the IP layer.

#endif

_u16

_u16

_u16

_u16

_u32

_u32

Figure 12-15: Route of a packet through the IP layer.

The program flow for send and receive operations is not always separate and may be interleaved if packets are only forwarded via the computer. The packets are not passed to higher protocol layers (or to an application) but immediately leave the computer bound for a new destination.

Continue reading here: Receiving Packets

Was this article helpful?

0 0