TCP/IP Model: Internet Protocol

To properly learn something, we have to start at the beginning. We will be learning one concept at a time, process it, and move to the next.

The goal is consistent learning and absorbing information while feeling engaged and not overwhelmed.

I have divided the network layer articles into six parts.

  1. Introduction to Network layer
  2. Addressing in Network layer
  3. Decoupling the Router
  4. Routing and Routing Protocols in Network Layer
  5. Internet Protocol
  6. DHCP and NAT in Network layer

Goal of this article

We have discussed the notion of the network layer's data and control plane component, the distinction between forwarding and routing, the identification of Internet addressing, look inside a router, and the routing protocols in the network layer. This discussion has often been without reference to any specific computer network architecture or protocol.

In this article, I'll focus on critical aspects of the network layer's celebrated Internet Protocol (IP).

The Internet Protocol (IP)

There are two versions of IP in use today

  • IPv4
  • IPv6

IPv4

  • The network layer contains information in the form of datagrams.
  • The datagram plays a central role on the Internet.

IPv4 Datagram Format

IPv4 Datagram

  • Version number

    • The version number is 4 bits.
    • It specifies the IP protocol version of the datagram that helps determine the remainder of the IP datagram.
  • Header length

    • The header length is 4 bits.
    • IPv4 datagram can contain a variable number of options included in the datagram header. These 4 bits are needed to determine the beginning of the payload in the IP datagram.
    • Most IP datagrams do not contain options, so the typical IP datagram has a 20-byte header.
  • Type of service

    • The Type of service (TOS) bits are included in the IPv4 header to allow different IP datagrams to be distinguished from each other.
    • The two of the TOS bits are used for Explicit Congestion ­Notification.
  • Datagram length

    • This is the total length of the IP datagram (header plus data), measured in bytes. Since this field is 16 bits long, the IP datagram's theoretical maximum size is 65,535 bytes.
    • Datagrams are rarely larger than 1,500 bytes, which allows an IP datagram to fit in the payload field of a maximally sized Ethernet frame.
  • Identifier, flags, fragmentation offset

  • Time-to-live

    • The time-to-live (TTL) field is included to ensure that datagrams do not circulate forever (due to, for example, a long-lived routing loop) in the network.
    • This field is decremented by one each time a router processes the datagram. If the TTL field reaches 0, a router must drop that datagram.
  • Protocol

    • This field is typically used only when an IP datagram reaches its final destination.
    • The field's value indicates the specific transport-layer protocol to which the data portion of this IP datagram should be passed.
    • A value of 6 indicates that the data portion is passed to TCP, while 17 indicates that the data is passed to UDP.
    • The protocol number is the glue that binds the network and transport layers together.
  • Header checksum

    • The header checksum aids a router in detecting bit errors in a received IP datagram.
    • The header checksum is computed by treating every 2 bytes in the header as a number and summing these numbers using 1s complement arithmetic. The 1s complement of this sum, known as the Internet checksum, is stored in the checksum field.
    • A router computes the header checksum for each received IP datagram and detects an error condition if the checksum carried in the datagram header does not equal the computed checksum.
    • Routers typically discard datagrams for which an error has been detected. Note that the checksum must be recomputed and stored again at each router since the TTL field and possibly the options field will change.
    • Why does TCP/IP perform error checking at both the transport and network layers?

      • Only the IP header is checksummed at the IP layer, while the TCP/UDP checksum is computed over the entire TCP/UDP segment.
      • TCP/UDP and IP do not necessarily both have to belong to the same protocol stack.
  • Source and destination IP addresses

    • When a source creates a datagram, it inserts its IP address into the source IP address field and inserts the final destination's address into the destination IP address field.
    • The source host determines the destination address via a DNS lookup.
  • Options

    • The options fields allow an IP header to be extended.
    • Header options were meant to be used rarely.
    • The existence of options complicates matters since datagram headers can be of variable length. One cannot determine a priori where the data field will start.
    • Some datagrams may require options processing, and others may not. The amount of time needed to process an IP datagram at a router can vary greatly. These considerations become particularly important for IP processing in high-performance routers and hosts.
  • Data (payload)

    • The IP datagram contains the transport-layer segment (TCP or UDP) to be delivered to the destination.

IPv4 Datagram Fragmentation

I discussed before that not all data link layer protocols could carry network-layer packets of the same size. The maximum amount of data that a link-layer frame can carry is called the maximum transmission unit (MTU). Each IP datagram is encapsulated within the data link-layer frame for transport from one router to the next router, and the MTU of the data link-layer protocol places a hard limit on the length of an IP datagram.

The solution for squeezing the oversized IP datagram into the data link-layer frame's payload field is to fragment the IP datagram into two or smaller IP datagrams and encapsulate each of these smaller IP datagrams in a different link-layer frame and send these frames over the outgoing link.

Each of these smaller datagrams is referred to as a fragment.

Working of Fragmentation

  • When a destination host receives a series of datagrams from the same source, it needs to determine whether any of these datagrams are fragments of some original, larger datagram.
  • If some datagrams are fragments, it must further determine when it has received the last fragment and how the fragments received should be pieced back together to form the original datagram.
  • Identification, flag, and fragmentation offset fields help the destination host to perform these reassembly tasks.
  • When a datagram is created, the sending host stamps the datagram with an identification number and source and destination addresses. Typically, the sending host increments the identification number for each datagram it sends.
  • When a router needs to fragment a datagram, each resulting datagram (that is, fragment) is stamped with the source address, destination address, and identification number of the original datagram. When the destination receives a series of datagrams from the same sending host, it can examine the datagrams' identification numbers to determine which of the datagrams are fragments of the same larger datagram.
  • For the destination host to be sure it has received the last fragment of the original datagram, the last fragment has a flag bit set to 0, whereas all the other fragments have this flag bit set to 1.
  • The offset field is used to specify where the fragment fits within the original IP datagram that helps the destination host determine whether a fragment is missing.

IPv6

A single 32-bit number can represent 4,294,967,295 unique numbers that sound like a lot, but there are more than 7 billion humans on earth. This means that the IPv4 standard doesn't even have enough IP addresses available for every person on the planet. It also can account for entire data centers filled with thousands and thousands of computers required for large-scale technology companies to operate. To respond to this need for an ample IP address space, a new IP protocol, IPv6, was developed. The designers of IPv6 also took this opportunity to tweak and augment other aspects of IPv4, based on the accumulated operational experience with IPv4.

IPv6 Datagram Format

The critical changes in IPv6 from IPv4 are:

  • Expanded addressing capabilities

    • IPv6 increases the size of the IP address from 32 to 128 bits.
    • In addition to unicast and multicast addresses, IPv6 has introduced a new type of address, called an anycast address, that allows a datagram to be delivered to any one of a group of hosts.
  • Streamlined 40-byte header

    • Some IPv4 fields have been dropped or made optional resulting in the 40-byte fixed-length header allows for faster processing of the IP datagram by a router.
    • A new encoding of options allows for more flexible options processing.
  • Flow labeling

    • IPv6 has an elusive definition of a flow that allows "labeling of packets belonging to particular flows for which the sender requests special handling, such as non-default quality of service or real-time service.

IPv6 Datagram

  • Version

    • This 4-bit field identifies the IP version number. Not surprisingly, IPv6 carries a value of 6 in this field. Note that putting a 4 in this field does not create a valid IPv4 datagram.
  • Traffic class

    • The 8-bit traffic class field, like the TOS field in IPv4, can be used to give priority to certain datagrams within a flow or can be used to give priority to datagrams from certain applications (for example, voice-over-IP) over datagrams from other applications (for example, SMTP e-mail).
  • Flow label

    • This 20-bit field is used to identify a flow of datagrams.
  • Payload length

    • This 16-bit value is treated as an unsigned integer giving the number of bytes in the IPv6 datagram following the fixed-length, 40-byte datagram header.
  • Next header

    • This field identifies the protocol to which the contents (data field) of this datagram will be delivered (for example, TCP or UDP).
    • The field uses the same values as the protocol field in the IPv4 header.
  • Hop limit

    • The contents of this field are decremented by one by each router that forwards the datagram.
    • If the hop limit count reaches zero, the datagram is ­discarded.
  • Source and destination addresses

    • The IPv6 128-bit address of source and destination.
  • ** data**

    • This is the payload portion of the IPv6 datagram.
    • When the datagram reaches its destination, the payload will be removed from the IP datagram and passed on to the protocol specified in the next header field.

We notice that several fields appearing in the IPv4 datagram are no longer present in the IPv6 datagram:

  • Fragmentation/reassembly

    • IPv6 does not allow for fragmentation and reassembly at intermediate routers. These operations can be performed only by the source and destination.
    • If an IPv6 datagram received by a router is too large to be forwarded over the outgoing link, the router drops the datagram and sends a "Packet Too Big" ICMP error message back to the sender. The sender can then resend the data using a smaller IP datagram size.
    • Fragmentation and reassembly is a time-consuming operation. Removing this functionality from the routers and placing it squarely in the end systems considerably speeds up IP forwarding within the network.
  • Header checksum

    • The transport-layer and data link layer protocols perform checksumming, which meant that the header checksum functionality was sufficiently redundant in the network layer, and we can remove the header checksum.
  • Options

    • The options field is no longer a part of the standard IP header.
    • The options field is one of the possible next headers pointed to from within the IPv6 header.
    • The removal of the options field results in a fixed-length, 40-byte IP header.

Did you find this post helpful?

I would be grateful if you let me know by sharing it on Twitter!

Follow me @ParthS0007 for more tech and blogging content :)