Home arrow Site Administration arrow Page 4 - Fundamentals (of Linux Networking)

Internet Protocol - Administration

This article discusses the various types of networks, the methods for connnecting networks, how network data is moved from network to network, and the protocols used on today's popular networks. It is excerpted from chapter one of the book The Definitive Guide to Linux Networking Programming, written by Keir Davis et. al. (Apress, 2004; ISBN: 1590593227).

  1. Fundamentals (of Linux Networking)
  2. Addressing
  3. Internet Addresses
  4. Internet Protocol
  5. Protocol Layering
  6. User Datagram Protocol
  7. The Client-Server Model
  8. The Domain Name System
By: Apress Publishing
Rating: starstarstarstarstar / 22
October 27, 2005

print this article



So far, we’ve discussed building a network based on Ethernet. We’ve also discussed connecting two or more networks together via a gateway, called an internet, and we’ve covered the basic issues surrounding network and host addressing that allow network nodes to communicate with each other without conflicts. Yet how are all of these dissimilar networks expected to communicate efficiently without problems? What is it that lets one network look the same as any other network?

A protocol exists that enables packet exchanges between networks as if the connected networks were a single, homogenous network. This protocol is known as the Internet Protocol, or IP, and was defined by RFC 791 in September 1981. These interconnected networks are known as internets, not to be confused with the Internet. The Internet is just one example of a global internet, albeit the most popular and the most well known. However, this does not preclude the existence of other internets that use the same technologies, such as IP.

Because IP is hardware independent, it requires a hardware-independent method of addressing nodes on a network, which is the IP addressing system already discussed. In addition to being hardware independent and being a packet-switching technology, IP is also connectionless. IP performs three key functions in an internet:

  • It defines the basic unit of data transfer.
  • It performs the routing function used by gateways and routers to determine which path a packet will take.
  • It uses a set of rules that allow unreliable packet delivery.

These rules determine how hosts and gateways on connected networks should handle packets, whether a packet can be discarded, and what should happen if things go wrong.

Like the physical Ethernet frame that contains data as well as header information, the basic unit of packet transfer used by IP is called the Internet datagram. This datagram also consists of both a header portion and a data portion. Table 1-4 lists the format of the IP datagram header, along with the size of each field within the header.

Table 1-4. IP Datagram Header Format





4 bits

The version of IP used to create this



4 bits

The length of the datagram header,



measured in 32-bit words


8 bits

Specifies how the datagram should be





16 bits

The total length of the datagram,



measured in octets


16 bits

A unique integer generated by the



sender that allows accurate datagram





3 bits

Various control flags, such as whether



the datagram may be fragmented


13 bits

Indicates where in the datagram this



fragment belongs


8 bits

Specifies how long, in seconds, the



datagram is allowed to exist


8 bits

Specifies which higher-level protocol



was used to create the data in the data



portion of the datagram


16 bits

Checksum for the header, recomputed



and verified at each point where the



datagram is processed


32 bits

IP address of the sender


32 bits

IP address of the recipient



Any number of various options, typically



used for testing and debugging



Contains the number of zero bits



needed to ensure the header size is an



exact multiple of 32 bits

Figure 5-6.  IP datagram encapsulation in an Ethernet frame

Most of these fields look pretty similar to the description of an Ethernet frame. What is the relationship between Ethernet frames, or packets, and IP datagrams? Remember that IP is hardware independent and that Ethernet is hardware. Thus, the IP datagram format must be independent of the Ethernet frame specification. In practice, the most efficient design would be to carry one IP datagram in every Ethernet frame. This concept of carrying a datagram inside a lower-level network frame is called . When an IP datagram is encapsulated within an Ethernet frame, it means the entire IP datagram, including header, is carried within the portion of the Ethernet frame, as shown in Figure 1-6.

We’ve said that an Ethernet frame has a maximum size of 1500 octets. Yet an IP datagram has a maximum total length of 16 bits. A 16-bit number can represent a data size of up to 65,535 octets and could potentially be much higher. How do we cram 65,535 octets into a network frame that maxes out at 1500? By using a technique called fragmentation.

Fragmentation is necessary in network protocols because the goal should be to hide the underlying hardware used to create the network. In our case, it’s Ethernet, but in practice it could be any number of different systems, past or future. It wouldn’t make sense to require changes to higher-level protocols every time someone invented a new hardware network technology, so to be universally compatible, the designers of IP incorporated the ability to split IP datagrams into fragments, assigning one fragment per network frame in the most efficient way possible.

The IP protocol does not guarantee that large datagrams will be delivered without fragmentation, nor does it limit datagrams to some smaller size. The sending node determines the appropriate datagram size and performs the fragmentation, while the receiving node performs the reassembly. The reassembly is made possible by the fragment offset field of the datagram header, which tells the receiver where this particular fragment should go. When the datagram is fragmented, each fragment carries a header that is essentially a duplicate of the original datagram header, with some minor changes. The fragment’s header differs because, if there are more fragments, the “more fragments” flag is set, and the fragment offset will change on each fragment to prevent overwriting.

Thus, an IP datagram of 4000 octets might get fragmented into three Ethernet frames, two containing the maximum data size and the third containing what’s left. On the receiving end, these fragments would be reassembled into the original datagram and would be processed. If our physical network had a smaller frame size than Ethernet, we would get more fragments, and less fragments (or no fragments at all) with a larger frame size.

Gateways are responsible for converting packets from one frame size to another.

Every network has a maximum transfer unit, or MTU. The MTU can be any size. If your packets are sent from a network with a large MTU value to a network with a smaller value (or vice versa), the gateway between the two is responsible for reformatting the packets to comply with each network’s specifications. For example, say you had a gateway with an Ethernet interface and a Token Ring interface. The MTU on one network is 1500 octets, while the MTU on the Token Ring network might be larger or smaller. It is the gateway’s responsibility to reformat and fragment the packets again when moving from one network to another. The downside to this is that once fragmented to accommodate the smaller MTU, the packets aren’t reassembled until they reach their destination. Thus, the receiving node will receive datagrams that are fragmented according to the network with the smallest MTU used in the transfer. This can be somewhat inefficient, since after traversing a network with a small MTU, the packets might traverse a network with a much larger MTU without being reformatted to take advantage of the larger frame size. This minor inefficiency is a good trade-off, however, because the gateways don’t need to store or rebuild packet fragments, and the packets can be sent using the best path without concern for reassembly problems for the destination node.

>>> More Site Administration Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: