TCP0010: CHAPTER 5: INTERNET PROTOCOL (IP)

I. Introduction

Think of IP as the workhorse of the TCP/IP world. Everything—TCP, UDP, ICMP, IGMP—gets carried around in IP datagrams.

IP is connectionless and provides a best-effort delivery service. Let’s unpack what that really means:

Best-effort: IP tries its best to deliver datagrams, but there are no guarantees. Sometimes packets get lost if a router’s buffers are full, and IP just drops them—usually the last one that arrived. 

Reliability isn’t IP’s job; that’s why we have protocols like TCP on top of it. Both IPv4 and IPv6 use this do your best delivery model.

Connectionless: IP doesn’t keep track of any ongoing conversation. Each datagram is handled independently. This has a few interesting consequences:

• Datagrams can arrive out of order. If you send A and then B, B might show up first.

• Datagrams can be duplicated or even corrupted along the way.

• Upper-layer protocols (like TCP) take care of fixing these issues to provide a smooth, error-free experience for applications.

II. IPv4 vs IPv6 Headers

Let’s peek inside the datagrams themselves.

III. IPv4 Header

• Variable size: Up to 15 × 32-bit words → max 60 bytes.

• Typical size: 20 bytes (if no options).

• Addresses: 32 bits each for source and destination.

• Fragmentation: Most of the second 32-bit word handles this.

• Checksum: Ensures the header fields arrive correctly. Note: it doesn’t protect the payload data.

IV. IPv6 Header

• Fixed size: Always 40 bytes.

• Addresses: 128-bit source and destination.

• Next Header field: Points to extra headers (extensions) that may include special instructions for processing. Think of this as a daisy chain of headers leading to the actual application data.

• Payload: Usually follows immediately after the transport-layer header.

So basically, IP is like the mail carrier of the Internet: it doesn’t promise that every letter (datagram) will arrive, or that they’ll arrive in order, but it will get each one on its way. The higher-level protocols (like TCP) are the ones that make sure the letters arrive safely and in the right order.

Both IPv4 and IPv6 headers are the structures that sit at the network layer and carry IP datagrams across the network. They define how packets are addressed, routed, and verified.

I. Basic Header Sizes and Structure 

II. Big Endian (Network Byte Order)

All fields in IP headers use big endian format.

Bits 0–7 are transmitted first, bits 8–15 next, etc.

Important because CPUs (like x86) often use little endian internally, so conversion is required when sending/receiving packets.

What is Big Endian (BE)?

Big Endian is a specific way of representing binary data – specifically, network data – that's commonly used in computer networks. 

It’s a bit-oriented representation that has a very important characteristic: bits 0-7 are transmitted first, followed by bits 8-15, and so on.

The Core Principle: Byte Order

The key to understanding BE is the concept of byte order. In computer science, byte order refers to the order in which bytes (groups of 8 bits) are arranged. BE is a specific type of byte order. Think of it like this:

Little Endian (LE): Bits are arranged in a sequence where the least significant bit (LSB – the first bit) comes first.

Big Endian (BE): Bits are arranged in a sequence where the most significant bit (MSB – the last bit) comes first.

How the Bits are Organized - A Step-by-Step Breakdown

Let’s look at the bits in a typical IP header and how they’re arranged:

Bits 0-7: These bits are always transmitted first. They carry the identity information for the packet. This includes the packet's source address and destination address. Think of these as the fingerprints of the packet.

Bits 8-15: These bits are transmitted after the first 7. They represent the protocol information for the packet. This includes the destination port and the protocol being used.

Bits 16-31: These bits are transmitted after the first 15. These bits are typically used to define the network portion of the IP header, like the network layer (IP) and the transport layer (TCP or UDP).

Bits 32-63: These bits are transmitted after the first 31. These bits provide further network information, which isn't as important to the data being transmitted.

Bits 64-71: These bits are transmitted after the first 31. These are the final bits of the IP header.

Why is Big Endian Important?

• CPU Compatibility: This is the critical reason. Modern CPUs, especially x86 architectures, primarily use little-endian internal representation. This means they store data in a sequence where the LSB (least significant bit) is first. When a CPU receives data, it expects it to be little-endian.

• Conversion: When you send data over a network, the CPU will always convert the data to little-endian internally before it’s actually sent. The reverse process is also true when the CPU receives the data. It's a crucial synchronization mechanism.

• Reliable Transmission: The BE format helps ensure the integrity of the data by correctly ordering the bits. It's a relatively simple mechanism, but it’s highly effective.

• Data Integrity: By putting the MSB first, the BE format helps to keep the packet data accurate.

Imagine you're writing a message with numbers on it.

• Little Endian: You write numbers in ascending order (1, 2, 3, ...). The first number is the most important.

• Big Endian: You write numbers in descending order (32, 31, 30, ...). The last number is the most important.

In essence, Big Endian is a standardized way to represent binary data that is vital for efficient communication across networks, particularly between CPUs and network devices.

III. Version and Header Length

Version (4 bits): This signifies the version of the Internet Protocol (IP) being used.

IPv4: 4 bits correspond to 4 versions (versions 1, 2, 3, and 4). This allows for a layered approach to IP addressing, supporting different levels of detail and addressing schemes.

IPv6: 6 bits correspond to 6 versions (versions 2, 3, 4, 5, 6, and 7). This represents a significant expansion of the IP address space, allowing for a much larger number of unique addresses.

IPv4 Header Length (IHL, 4 bits): This defines the number of 32-bit words (fields) within the IPv4 header.

Normal IPv4 Header: A standard IPv4 header consists of 5 fields:

• Logical Entity (Legend) – 1 field (4 bits)

• Prefix (Identifier) – 1 field (4 bits)

• Hop Limit – 1 field (4 bits)

• Total Length – 1 field (4 bits)

• Identification – 1 field (4 bits)

• Source Address – 4 fields (4 bits each).

• Destination Address – 4 fields (4 bits each).

• Total IHL = 5 * 4 = 20 bytes.

IPv6: Fixed Header Length of 40 Bytes → No IHL Field: This is a crucial departure. IPv6 employs a fixed-length header, meaning the header data is constant regardless of the data payload size. This simplifies routing significantly.

Rationale: The fixed header length allows for a more streamlined and efficient routing process. Instead of needing to calculate the maximum length of the header based on the data, routers only need to check the header length, making packet processing faster. This eliminates the complexity associated with header length calculations.

Implication – Why is this a significant design choice?

The shift to a fixed-length IPv6 header has far-reaching consequences:

1. Simplified Routing: The biggest benefit. Routers don't need to spend valuable processing power calculating and verifying the header length. This dramatically reduces computational load, especially on routers with limited resources.

2. Increased Routing Throughput: Less processing time translates into faster packet forwarding. This increases the overall throughput of the network.

3. Reduced Complexity: The code written to handle the fixed-length IPv6 header is simpler. It’s less likely to encounter errors or vulnerabilities associated with header calculations.

4. Foundation for Scalability: The fixed header length makes it easier to scale the IPv6 network as it grows. The reduced overhead will be more sustainable.

5. Compatibility with Existing Infrastructure: The design enables a more seamless transition to IPv6 by reducing the required modifications to existing network infrastructure and protocols.

Type of Service / Traffic Class

• Helps routers handle priority traffic and congestion notification.

• Widely adopted in modern QoS networks (DSCP values).

I. Total Length / Payload Length

IPv4 Total Length (16 bits): This is fundamentally designed to handle the massive growth of the internet’s address space. The 16-bit field allows for a much larger address space (4.3 billion addresses) compared to the 32-bit IPv3 address space. This was a key constraint in the early years of the Internet and remains crucial for future scalability.

Maximum Datagram: 65,535 Bytes: This represents the practical maximum size of a datagram (a single packet) that an IPv4 network can handle. While it’s a reasonable upper limit, it’s a practical limit reflecting the limitations of network bandwidth and processing capabilities.

Hosts Must Support at Least 576 Bytes: This is a crucial metric for IPv6’s design. It establishes a minimum size for IPv6 datagrams to be accepted, providing a foundation for widespread adoption. It’s a safety net for early network deployments.

Fragmentation Occurs if Datagram Exceeds MTU: This is a core design decision driven by the inherent limitations of network paths. IPv6’s stateless nature avoids the complexities of router-side fragmentation. The endpoint (device) is responsible for determining the maximum size of a datagram, simplifying network design.

II. Identification and Fragmentation

IPv4 Identification Field: 16-bit Counter: The 16-bit counter is critical for IPv4’s layered addressing scheme. It allows for the creation of a unique identifier for each datagram, even as the address space grows. It’s a simple, efficient way to track packet flow.

Fragments of the Same Datagram Share the Same ID: This is a cornerstone of IPv6’s design. Fragmentation happens at the source (e.g., a client sending data). Instead of routers needing to figure out the size of the full datagram, fragmentation is handled by the device sending the data, leading to simpler network routing.

Practical Takeaway: IPv6 avoids router-side fragmentation, reducing processing overhead. This is a huge win. It simplifies routing significantly. Routers spend less time examining data and can focus on forwarding packets.

III. Time-to-Live / Hop Limit

IPv4 TTL: Initial Value Set by Sender (64): The initial TTL (Time to Live) determines how many hops a packet can traverse before being discarded. It's a basic mechanism for preventing routing loops.

Hop Limit: Same Function, Renamed: The core purpose of the hop limit is to prevent packets from looping endlessly. It acts as a way to determine when a router should discard a packet, simplifying routing.

Routers Must Decrement TTL/Hop Limit Even if Incorrectly Forwarded: This is a brilliant detail. It creates a cascading effect—if a router misinterprets the packet, it has to decrement the TTL/Hop Limit on every router it passes through, effectively triggering a re-transmission. This significantly reduces router processing and improves reliability.

IV. Protocol / Next Header

IPv6: No Identification in Base Header: The absence of an identification field means that the header doesn’t have a specific purpose. It’s treated as a general data field – it’s only useful for extending the header with a fragment extension.

Next Header: Generalizes IPv4 Protocol: This standardization allows for flexible packet structure. The next header field can specify transport protocols (TCP, UDP) or extension headers (routing, fragmentation, AH, ESP), opening doors to more complex data transmissions.

Enables Flexible Packet Structures with Chained Headers: The ability to specify a next header is essential for building more sophisticated network protocols. It allows for applications to tailor headers – for example, routing protocols – to carry specific information.

V. Header Checksum

IPv4: 16-bit Checksum Covers Only Header: This makes IPv4 more vulnerable to errors. A single incorrect bit in the header can cause a packet to be discarded, increasing router processing.

IPv6: No Checksum in Header: The elimination of checksums is a deliberate design choice to reduce processing overhead on routers. Checksums are resource-intensive and can be ignored by the network layer.

Reason: Higher Layers Have Checksums: The core principle is that the higher layers (TCP, UDP, ICMPv6) are responsible for validating the integrity of the data payload. Router processing is minimized by trusting these layers.

VI. Source and Destination Addresses

IPv4: 32-bit Addresses, Supports ~4.3 Billion Hosts: The massive address space is a fundamental design choice to accommodate the exponential growth of the internet's connectivity.

IPv6: 128-bit Addresses, Supports 3.4 Million Hosts: The 128-bit address allows for a vastly greater number of unique addresses, mitigating the limitations of IPv4’s address space. A fundamental change to increase overall addresses.

Eliminates Address Exhaustion: A core goal of IPv6 is to eliminate the need for NAT (Network Address Translation), a major source of complexity and performance bottlenecks.

Each Device Can Have Multiple Addresses (Global, Link-Local, Temporary): This fundamentally changes how networks are configured. It simplifies the management of network infrastructure, and allows for seamless communication between devices.

VII. Time-to-Live / Hop Limit

IPv4 TTL: Initial Value Set by Sender (64): The initial TTL is a very simple mechanism to prevent routing loops.

Hop Limit: Same Function, Renamed: This defines a boundary that routers automatically trigger. It functions as a simple congestion control mechanism, decreasing the likelihood of packets looping indefinitely.

 This cascading mechanism enhances reliability. It’s a way for routers to re-transmit lost packets, improving the chances of successful delivery.

VIII. Protocol / Next Header

IPv6: No Identification in Base Header: This further simplifies the header structure, enabling a more flexible and adaptable packet structure.

Next Header: Generalizes IPv4 Protocol: This allows for varied header types, potentially incorporating extra information for data-specific purposes.

Enables Flexible Packet Structures with Chained Headers: It facilitates the creation of complex, multi-layered data transfer, supporting new application use cases.

IX. Header Checksum

IPv4: 16-bit Checksum Covers Only Header: A simple checksum makes IPv4 more vulnerable.

IPv6: No Checksum in Header: A core principle of IPv6 – the checksum is handled by the higher-layer protocols.

Reason: Higher Layers Have Checksums: The design prioritizes the validation of data payload by layers above, allowing the core protocol to execute quickly.

X. Source and Destination Addresses

IPv4: 32-bit Addresses, Supports ~4.3 Billion Hosts: The massive address space is a fundamental design choice.

IPv6: 128-bit Addresses, Supports 3.4 Billion Hosts(2128): The 128-bit address provides a dramatically increased address space, facilitating the expansion of internet connectivity.

Eliminates NAT: A core benefit, because NAT is generally inefficient for large, complex networks. IP addresses are used more simply.

Each Device Can Have Multiple Addresses (Global, Link-Local, Temporary): Simplifies network management.

XI. Practical Summary of IPv4 vs IPv6 Headers

✅ Key Takeaways

1. IPv6 simplifies routers: fixed header, no checksum, no router fragmentation.

2. IPv6 supports huge addressing: solves IPv4 scarcity problem.

3. IPv6 allows extension headers: flexible features without bloating base header.

4. IPv6 relies on higher layers: correctness and fragmentation moved to endpoints.

5. IPv6 is forward-looking: handles QoS, congestion, and modern security better.

The Internet checksum is a simple yet effective way to detect errors in IP headers. 

It’s a 16-bit sum that helps the receiver verify, with high probability, whether a message arrived intact.

⚠️ Note: This is not the same as a CRC (cyclic redundancy check), which is stronger but more complex. The Internet checksum is lighter and good enough for IPv4 headers.

How the Checksum is Calculated

Step 1: Prepare the header

Before calculating the checksum, set the Checksum field to 0 in the IPv4 header.

Step 2: Compute the sum

Treat the header as a sequence of 16-bit words.

Add them together using one’s complement addition:

If the addition produces a carry (overflow past 16 bits), wrap it around and add it back into the sum. This is sometimes called end-around-carry addition.

Step 3: Take the one’s complement

Invert all bits of the sum to get the checksum.

Store this 16-bit value in the Checksum field.

This prepares the header for transmission.

Example Calculation

Suppose we have a message with these 16-bit words:

Step 1: Add the words using one’s complement addition

Step 2: Take one’s complement

✅ The checksum to send: 1AFF.

Step 3: Verification at the receiver

Add all words including the checksum:

• Take the one’s complement of the total: ~FFFF = 0000 ✅

• Result = 0 → header is valid.

If the result is nonzero → header is corrupt, discard the packet.

💡 Key point: IPv4 does not send error messages for bad headers. Higher layers (like TCP) handle retransmission if necessary.

Rules & Details

One’s complement addition is critical: wrap around any carry bit.

Checksum field must be 0 during calculation.

If the data has an odd number of bytes, zero padding is added to make 16-bit words.

Correctly received data with checksum will always sum to FFFF, so one’s complement = 0.

Invalid headers are simply discarded by the receiver, no ICMP message is generated.

Key Takeaways

Lightweight error detection for IPv4 headers.

Computed on 16-bit words using one’s complement sum.

Verification: checksum + data → sum = 0 → valid.

Simple, fast, and sufficient for header integrity (not payloads).

If you like a bit of math with your networking, the Internet checksum is a neat example of a 16-bit one’s complement sum forming a special algebraic structure called an Abelian group. 

Don’t worry, we’ll break it down step by step.

I. Why 0000 is excluded (IPv4 checksum rules)

In IPv4, the internet checksum is computed as the one's complement of the 16-bit sum of the data (including the 4-byte header). The key requirement is that the final checksum must be zero.

If we include 0000 as the checksum, we have a problem:

Let’s say the data we want to send has a checksum field (like in IPv4’s checksum field).

The checksum field itself is a 16-bit number, but it must be exactly 0000 for the total checksum to be zero.

II. What happens if we include 0000?

Suppose we include 0000 as the checksum:

Data + Checksum = Total

If the data is ABCD, and the checksum is 0000, the total becomes:

ABCD + 0000 = ABCD (since 0000 is zero).

For this to equal the checksum field (which is 0000), we must have ABCD = 0.

But this creates a contradiction for most data:

• If we try to send data that is not zero, including 0000 as a checksum would make the total checksum non-zero.

• The checksum must be always 0, so we need to design it so that the sum of the data bits plus the checksum equals zero.

The correct way to handle it

The checksum is calculated as:

1. Sum the 16-bit data words (header + data).

2. Take one's complement (flip all bits).

3. Ensure the result is 0.

III. Why not just use 0000?

If we use 0000 as the checksum, the final checksum is 0, which is valid.

But if the data itself is not zero, we must ensure the sum (plus checksum) equals zero.

Including 0000 as a safety net forces us to design the checksum calculation so that it's independent of the data.

IV. Key Point

0000 is excluded because it forces the checksum to be 0, which might not always align with the data.

The IPv4 checksum is carefully designed to ensure the total checksum (data + checksum) equals zero.

The one's complement method works because it guarantees that if the sum of the data is X, the checksum is -X, and flipping bits ensures the final value is 0.

The exclusion of 0000 is about mathematical consistency in the checksum algorithm, not just a technical detail. It ensures the checksum is always zero, which is the core requirement for IPv4. 

IPv6 uses a much larger address space, but the checksum logic remains the same in principle.

V. Verifying a Checksum

When a packet is received:

1. Sum all 16-bit words including the checksum.

2. Take the one’s complement of that sum.

3. If everything is correct, the result should be 0000.

This works because the checksum field is essentially the inverse of the sum of the rest of the data.

VI. Key Takeaways

The Internet checksum is simple but clever: it uses one’s complement arithmetic to detect errors.

The set VVV forms an Abelian group, but 0000 must be excluded to maintain group properties.

Checksum verification is just a sum + one’s complement test → 0 means all good.

I. DS Field (Differentiated Services Field)

Location: This field resides in the header (IPv4 or IPv6) and contains two bytes: the ToS byte (formerly the Type of Service byte) and the Traffic Class byte.

Purpose: Provides differentiated service classes beyond basic best-effort delivery. It allows for more granular control over how traffic is treated.

Framework: Utilizes the DiffServ standards ([RFC 2474], [RFC 2475], [RFC 3260]).

Mechanism:

• DSCPs: Use specific bit patterns to denote priority and service class.

• DSCP = Priority/Class: Bit patterns define the meaning of the DSCP – high priority, expedited forwarding, etc.

• Set at Ingress: DSCPs are initially set at the ingress point (when a packet enters the network).

• Policy Changes: DSCPs can be altered mid-path (e.g., limiting high-priority traffic) – a crucial element of dynamic QoS.

II. ECN (Explicit Congestion Notification) - Added as a Separate Field

Location: This is a second bit in the same field space as DSCPs.

Purpose: Signals congestion to the destination without dropping packets.

Mechanism:

• Routers Set ECN Bits: Network devices (routers) automatically set both ECN bits when congestion occurs.

• Destination Hosts See Mark: The destination host detects the ECN signal.

• TCP Signaling: The transport protocol (like TCP) notifies the sender.

• Sender Reduces Rate: The sender reduces transmission rate to ease congestion.

• Benefit: Avoids packet drops, improves congestion control efficiency, and allows protocols like TCP to proactively slow down before routers drop packets.

III. Relationship to ToS and Traffic Class

• Evolutionary Shift: The original ToS and Traffic Class fields were derived from older, broader definitions.

• DS Field + ECN = Modernization: The DS Field (DSCP) is the core of the change, providing both prioritization and congestion notification. ECN complements this, acting as a proactive congestion signal.

In essence, this is a move toward a more flexible and responsive network architecture that leverages DSCPs and ECN to optimize traffic flow and ensure reliable communication.

I. Prioritization through a Multi-Level System

The key idea is a tiered prioritization system built around three key subfields:

• Precedence Subfield (3 Bits): This is the fundamental starting point. It dictates the relative importance of the traffic. Think of it as a priority level for each packet.

• Larger Values = Higher Priority: The higher the number, the more important the traffic is considered. This is crucial for ensuring critical communications are handled first.

• MLPP (Multilevel Precedence and Preemption): This is the magic part. It’s a sophisticated system that allows higher-priority traffic to preempt (interrupt) lower-priority traffic. This isn't just about being 'better' – it’s about managing the flow of data effectively. It's a complex mechanism built into the system, ensuring that essential messages aren’t dropped or delayed when others are in use.

D, T, R Subfields (Delay, Throughput, Reliability): These subfields are the details of how the system actually prioritizes the traffic based on its precedence. They determine how the traffic is handled.

• D (Request Low Delay): If a traffic type has a higher priority (a larger value), it requests a lower delay. This means the system tries to minimize the time it takes for the data to travel. Delay is a critical factor – slower delays can lead to dropped packets or missed messages.

• T (Request High Throughput): If a traffic type has a higher priority, it requests higher throughput. This refers to the amount of data that can be successfully transmitted per unit of time. High throughput is vital for applications like streaming video, online gaming, and large file transfers.

• R (Request High Reliability): If a traffic type has a higher priority, it requests high reliability. This means the system prioritizes data integrity – it minimizes the chances of errors or data corruption during transmission.

II. Why This Design Matters - The Implications

Efficiency: By intelligently prioritizing traffic, the system is more efficient overall. It avoids bottlenecks and resource conflicts.

Robustness: The MLPP mechanism is designed to make the system more robust – it’s better able to handle disruptions and maintain functionality.

Specialized Applications: The system is tailored for specific applications where high priority is critical (e.g., military communications, critical data transmissions).

III. Precedence Values

III. The DS Field – Expanding the System

The DS field is a significant component of modern networking systems, providing a more granular and flexible approach to prioritizing traffic. This section will delve into the details of the DS field, exploring its components, structure, and functionality.

DSCP (Differentiated Services Code Point) Overview

• DSCP represents a 6-bit code point that defines how a router should handle a particular packet based on per-hop behavior (PHB). 

• It's a crucial signaling element for traffic prioritization and quality of service.

Key Components

• Class Selector Code Points: The first three bits (xxx000) determine the class of traffic, which is the fundamental grouping mechanism.

• First 3 Bits → Class Portion: These bits dictate the type of traffic, including its characteristics such as priority or performance requirements.

• DSCP Value: The last bit defines the pool to which the DSCP value applies. This creates a layered approach for traffic management.

ECN (Explicit Congestion Notification)

• ECN is an additional critical feature that ensures zero-loss congestion signaling. 

• It signals congestion to the sender before packet loss occurs, preventing network bottlenecks and maintaining overall stability.

IV. DSCP Pools – A Deeper Dive

The DS field is divided into distinct pools for specific purposes:

• Pool 0 (Default): Represents routine traffic with no specific QoS requirements.

• Pool 1: Traffic with higher priority, indicating urgent or emergency situations.

• Pool 2: Traffic with lower priority, suitable for general use cases such as web traffic.

• Pool 3: Critical services like VoIP and video conferencing.

• Pool 4: Testing and demo traffic, requiring special handling.

• Pool 5: Security-related traffic or monitoring activities.

• Pool 6: User-generated content, including social media and online forums.

• Pool 7: Advanced or specialized traffic with specific requirements.

Backward Compatibility

The DS field structure was designed to accommodate legacy precedence values, ensuring compatibility with older traffic classifications. 

However, modern networks are shifting towards more sophisticated QoS mechanisms like DSCP + ECN.

V. The DS Field Structure

Total Size: 8 bits

DSCP (6 bits):

• Class Selector Code Points: Determines the class of traffic.

• First 3 Bits → Class Portion: Specifies the type of traffic.

• DSCP Value: Defines the pool to which the DSCP value applies.

DSCP Pool Structure: Each pool has a unique combination of bits that define its characteristics and usage.

ECN (2 bits) + Signal Congestion Without Dropping

ECN adds an additional layer of control, ensuring zero-loss congestion signaling and preventing network degradation. 

It signals congestion to the sender before packet loss occurs, allowing for proactive adjustments to be made.

AF (Assured Forwarding) Layer – Expanding the Strategy

The AF layer introduces a new approach to traffic classification, enabling fine-grained control over flow:

• Level of Grouping: Traffic classes are grouped based on combined precedence and drop precedence.

• Multiple Classes per Class: Multiple separate PHBs can exist within each class for more nuanced prioritization.

• Naming Convention: Each class is assigned a specific PHB using the AFij convention (e.g., AF32 → Class 3, Drop Precedence 2).

• Generalizes Precedence → Multiple Independent Classes: The hierarchy of precedence levels allows for careful prioritization within each class.

Ensuring Forwarding (AF) – Beyond Basic Classification

The AF system goes beyond simple classification to guarantee proper traffic flow and mitigate congestion:

• Layered Approach: The DS field structure is now a multi-layered approach, consisting of Class Selector, AF, and DSCP components.

• Explicit Defining PHBs: The AF layer explicitly defines how each class must be handled, including drop precedence.

In summary, the DS field has evolved from simple prioritization to a sophisticated classification system coupled with explicit congestion signaling. 

The AF layer provides a structured approach for traffic management, guaranteeing proper flow and minimizing network issues.

Expedited Forwarding (EF) is a Per-Hop Behavior (PHB) in Differentiated Services (DiffServ) designed to provide the appearance of an uncongested network. Its primary goal is to ensure that EF traffic experiences low delay, low jitter, and low loss.

I. Key Features

Goal: To guarantee low delay, low jitter, and low loss for EF traffic.

EF Service Characteristics:

Only EF traffic should ever wait behind other EF traffic in router queues.

Rate-Based Queueing: The rate of EF traffic leaving a router must be at least as large as the rate entering to ensure proper waiting times.

II. Implementation Notes

Standardized in RFC 3246 (Expedited Forwarding PHB): EF is a standardized PHB.

Priority Queuing or Strict Scheduling: EF is often implemented using priority queuing or strict scheduling in routers.

Careful Configuration: To avoid starving other traffic classes, careful configuration is necessary.

III. Challenges

Complexity: DiffServ links involve technical mechanisms and economic models, making implementation complex.

Fairness: Ensuring EF traffic doesn't monopolize resources while delivering guaranteed QoS requires careful consideration.

Deployment: Although standardized in the late 1990s, widespread implementation only began in the 2000s.

IV. Key Takeaways

EF service is designed to prioritize real-time applications like VoIP and video conferencing, requiring strict bandwidth management.

It's often tied to differentiated pricing and QoS policies, making it a valuable tool for network optimization.

IP supports a set of optional features that can be specified on a per-datagram basis.

These are extra fields in the IP header that allow special handling of packets, mostly introduced back when IPv4 was first designed ([RFC0791]).

Back then, the Internet was smaller, and security threats were not as much of a concern. As a result:

Many IPv4 options are rarely used today

Some options are impractical due to limited IPv4 header size (max 60 bytes)

Security concerns and modern networking practices often make these options undesirable

In IPv6, options are handled differently:

Most are removed or moved to extension headers placed after the main header

Some are only processed by end hosts, not routers

Routers usually forward packets with options more slowly than standard packets

I. IPv4 Options: Basics

IPv4 options are extra fields in the header, always ending on a 32-bit boundary

Padding bytes (0s) are added if necessary to keep the header aligned

Each option has:

• Number: index of the option

• Value: placed in the Type field to indicate the option is present

II. Option Type field structure

1. High-order bit → Copy flag (whether the option should be copied into fragments if the packet is fragmented)

2. Next 2 bits → Option class:

• 0 = Control (most options)

• 2 = Debugging/measurement (e.g., Timestamp, Traceroute)

• 1 and 3 = Reserved

III. Why Most Options Are Rarely Used Today

• Options like Source Route and Record Route require embedding IPv4 addresses in the header

• IPv4 header is limited to 60 bytes, with 20 bytes for the standard header → very little space for options

• Average Internet path length is ~15 hops → most options are impractical for real-world use

• Many options are diagnostic or measurement tools, not for everyday traffic

• Enterprise firewalls often strip or disallow options to improve security

⚡ Tip: IPv4 options can still be useful in small, controlled networks (like enterprise LANs) where paths are short and the environment is trusted.

IV. Special Cases

Router Alert Option

• Exception among IPv4 options

• Signals routers that a packet needs special processing beyond normal forwarding

• Widely allowed because it optimizes performance without breaking router behavior

Quick-Start Option

Experimental option, available in both IPv4 and IPv6

We’ll cover it later under IPv6 extension headers and options

V. Summary

• IPv4 options are mostly legacy features: supported but rarely used

• They add extra processing overhead for routers and can complicate firewalls

• IPv6 handles options more cleanly using extension headers

• Only a few options like Router Alert remain commonly relevant

💡 Remember: Options are mainly for diagnostics, debugging, or special performance tweaks, not everyday Internet traffic.

IPv6 handles special packet functions (like IPv4 options) in a much cleaner and more flexible way: through extension headers that follow the main IPv6 header.

The main idea:

• The IPv6 header is fixed at 40 bytes

• Extra functionality is provided only when needed via extension headers

• This design makes high-performance router processing much simpler

⚡ Contrast with IPv4: many options in the IPv4 header complicated routers, made headers variable-length, and slowed packet forwarding. IPv6 fixes that with a clean separation of the core header and optional features.

I. Functions Supported via Extension Headers

Extension headers can provide:

• IPv4-style Routing and Timestamp functions

• Fragmentation support for large packets

• Optional features rarely used for most traffic but still needed

• Other specialized options without bloating the main header

By keeping the main header simple, routers mostly process just the 40-byte IPv6 header, leaving extension headers to end hosts (except for the Hop-by-Hop Options header, which routers do process).

II. Header Chaining

• Extension headers are chained together with the main IPv6 header and higher-layer headers (TCP, UDP, etc.)

• Each header contains a Next Header field, indicating the type of the next header in the chain

• A value of 59 indicates the end of the header chain

Example: 

IPv6 header → Hop-by-Hop Options → Routing → Destination Options → TCP → Payload

The exact order of extension headers is recommended but not mandatory, except:

• Hop-by-Hop Options header must always appear immediately after the IPv6 header

• Only the Destination Options header can appear twice:

  • 1. For options related to the address in the IPv6 header

    2. For options related to the final destination of the datagram

⚡ Special note: Some headers, like the Routing header, can change the Destination Address in the main IPv6 header as the packet moves toward its ultimate destination.

III. Key Advantages of IPv6 Extension Headers

• Fixed 40-byte header → simpler and faster for routers to process

• Optional features are modular, processed only when needed

• End hosts handle most of the complexity, not the routers

• Supports flexible features without compromising router performance

IV. Summary

• IPv6 replaces IPv4 options with extension headers

• Headers are chained, and each points to the next via the Next Header field

• Routers process only what they need (Hop-by-Hop is the exception)

• Some headers (Destination Options) can appear more than once

• Helps simplify packet forwarding while still supporting advanced functions

💡 Think of it like a conveyor belt: the core IPv6 header moves quickly through routers, and optional attachments (extension headers) are handled only when needed.

IPv6 HEADER CHAIN AND NEXT HEADER FIELD

IPv6 organizes headers in a chain, using the Next Header field to point to the next piece of the datagram.

The IPv6 header is always first and fixed at 40 bytes

Headers in the chain can be:

•  IPv6 extension headers (for options, routing, fragmentation, etc.)

•  Transport headers (TCP, UDP, ICMPv6, etc.)

This structure makes it easy for routers and hosts to process only the headers they care about, while maintaining flexibility for advanced features.

I. Next Header Field Values

The Next Header field indicates what type of header comes next. Some examples:

⚡ Tip: Many of these values are shared with IPv4’s Protocol field, so it’s easy to map between IPv4 and IPv6.

II. Hop-by-Hop Options Header

1. Mandatory Placement: This header must be placed immediately after the IPv6 header, making it essential for routers to process this header.

2. Routers Must Process It, ensuring that all required information is included.

III. Destination Options Header (Options)

• Dual Purpose: This header can appear twice:

• Destination Address in the IPv6 Header: Routers will modify the Destination Address field in the main IPv6 header as the packet progresses toward its final destination.

• Final Destination of the Datagram: The Destination Options header may also be used to specify options for the final destination of the datagram, allowing routers to prioritize or customize the delivery of packets.

IV. Processing Order

Recommended but Not Mandatory: The order in which headers are processed is recommended but not mandatory.

IPv6 Implementations Must Process Headers in Order: Routers must be prepared to process headers in the order received, regardless of their position in the header chain.

The key points to understand from this explanation:

• Hop-by-hop options give modularity to the IPv6 header by ensuring only relevant headers are processed.

• Keeping the main IPv6 header fixed simplifies packet forwarding and makes it easier for routers or hosts to process all required information.

• The hop-by-hop option allows flexible features like routing, fragmentation, security, and mobility without adding unnecessary overhead.

In essence, the presence of hop-by-hop options enables a more streamlined and efficient packet forwarding process by keeping the main header fixed and allowing specific headers (like Destination Options) to be processed separately.

IPV6 OPTIONS OVERVIEW

Extension Headers: In IPv6, each packet has a header with specific options that extend the basic packet structure. These extensions are called header extensions or extension headers.

Options: Options are used to carry additional data within the packet. They can be categorized into two types:

Hop-by-Hop (HOPOPT): Used for routing packets, and is processed by every router along the path.

Destination (DST): Processed only by the final recipient.

I. Format of Options:

• TLV Format: Each option is encoded using a Type-Length-Value (TLV) format, which consists of:

• Option Type (1 byte): Identifies the specific type of option.

• Change Bit (1 bit): Indicates if option data may change in transit.

• Type (5 bits): Identifies the specific option.

• Opt Data Len (1 byte): Size of option data.

• Option Data (variable length): Actual payload.

II. How Options are Carried:

• HOPOPT: Processed by every router along the path, and is not encoded in the TLV format.

• DST: Processed only by the final recipient.

III. Defined IPv6 Options 📊 

IV. Key Uses ⚡ 

• Pad1/PadN → alignment padding.

• Jumbo Payload → supports packets > 65,535 bytes.

• Tunnel Encapsulation Limit → prevents infinite tunneling loops.

• Router Alert → signals routers to examine packet (used in RSVP, IGMP, etc.).

• Quick-Start → experimental congestion control mechanism.

• CALIPSO → security labeling for packets.

• Home Address → used in Mobile IPv6 for mobility support.

✅ Key Takeaway

IPv6 options are flexible, extensible, and encoded in TLV format.

Hop-by-Hop Options → processed by every router.

Destination Options → processed only by the endpoint.

The Action subfield ensures graceful handling of unknown options, promoting incremental deployment.

The IPv6 Routing header is an extension header that allows the sender to partially control the path of a datagram through the network. 

It generalizes the IPv4 Source Route and Record Route options.

Each Routing header specifies a list of intermediate nodes (IPv6 addresses) that the packet should visit before reaching the final destination.

The IPv6 header’s Destination Address field is updated dynamically as the packet progresses through the listed nodes.

Two versions of the Routing header exist:

1. Type 0 Routing Header (RH0) – deprecated due to security concerns

2. Type 2 Routing Header (RH2) – used in Mobile IPv6

I. Routing Header Type 0 (RH0)

RH0 was the original IPv6 routing header type. It allowed multiple waypoints in the datagram path.

Structure of RH0

• Next Header (8 bits) – indicates the type of header following the Routing header

• Hdr Ext Len (8 bits) – length of the header in 8-octet units, not including the first 8 bytes

• Routing Type (8 bits) – value 0 for RH0

• Segments Left (8 bits) – number of addresses remaining to be visited (count of remaining waypoints)

• Reserved (32 bits) – set to 0, ignored by receivers

• Address Vector – list of non-multicast IPv6 addresses to be visited

Fields in Detail: 

RH0 Routing Logic

1. The sender constructs the packet with:

   • IPv6 Destination Address = first node (or the first hop in the normal IPv6 route)

   • RH0 containing all intermediate addresses plus the final destination

   • Segments Left = number of intermediate nodes + final destination

2. Forwarding behavior at each node:

If the current node’s IPv6 address matches the Destination Address in the IPv6 header:

• Swap the Destination Address with the next address in the Routing header list

• Decrement Segments Left by 1

The datagram is forwarded toward the new Destination Address, following the normal routing table if the new address isn’t directly reachable.

3. The process repeats until the Segments Left field reaches 0, meaning the final destination is reached.

Example Flow (RH0)

Ping Example Using RH0

• -r includes a Routing header (RH0)

• -s sets the source address

• Wireshark shows the Routing header with Segments Left = 1 and the next hop listed in the address vector

RH0 Loose vs Strict Addresses

• Strict address – must be reached by a single hop from the previous node

• Loose address – may include other intermediate hops in between

RH0 generalizes IPv4's loose/strict source routing.

RH0 Deprecation

RH0 is deprecated by RFC5095 because it poses a DoS vulnerability:

• RH0 allows the same address to appear multiple times in the routing list

• This can cause packets to loop repeatedly between two nodes

• Attackers can generate high traffic along specific paths, causing congestion and disrupting other traffic

✅ RH0 is no longer recommended; modern IPv6 networks should not use it.

II. Routing Header Type 2 (RH2)

RH2 is the current, supported routing header type, used mainly for Mobile IPv6.

Key Differences Between RH0 and RH2

RH2 Logic

In Mobile IPv6, only one intermediate address (the home agent) is allowed.

This single address is typically the base node in a segment.

When sending and receiving data, RH2 uses this single address to ensure safety from malicious attacks like DoS (Distributed Denial of Service) attacks.

Processing Rules for Routing Headers

1. Routing Header Processing: The routing header is only processed at nodes listed in the destination address.

If a node isn't on the list, it forwards the packet normally.

2. Segment Left Decrement: After swapping addresses, the segment left counter decreases.

3. Destination Address Update: Ensures the packet follows its intended path by updating the destination address.

4. Hop-by-Hop Header Processing: Starts with the hop-by-hop header and then processes the routing header before forwarding to the next node.

5. Multiple Destination Options (Optional): Only Destination Options can appear multiple times, after the routing header.

Summary of Concepts

IPv6 routing headers allow for partial path control by swapping addresses at each step.

RH0 allowed general source routing, but this led to security issues; RH2 resolves these problems by limiting addresses to one.

At each node in the routing header:

• Destination Address Swapped: Updates are made to ensure packets follow their intended paths.

• Segments Left Decremented: Keeps track of remaining segments to be processed.

• Packet Forwarding: Moves to the next address, decrementing segment left counter.

Visualization Concept

Think of the IPv6 routing header as a stack of addresses. Each node in the stack represents an address (e.g., IP address). 

When sending data, packets pop from the top of the stack (Destination Address), update their destination, and move down the stack until they reach the final destination.

RH0 allowed multiple items on the stack, while RH2 keeps it safe by limiting addresses to one at each node

In IPv6, fragmentation is only performed by the source node, unlike IPv4, where routers along the path can fragment packets. 

This is a design choice in IPv6 to simplify router processing.

• IPv6 defines a minimum link-layer MTU of 1280 bytes ([RFC2460, Section 5])

• If the datagram exceeds the MTU of the path to its destination, the source fragments it and adds a Fragment header

• The Fragment header contains information needed for the receiver to reassemble the original datagram

Structure of the IPv6 Fragment Header

The Fragment header is always 8 bytes long and has the following fields:

Fragment Offset:

Determines where each fragment belongs in the original datagram.

Measured in 8-byte increments (1 byte per fragment).

All fragments except the last must have payload lengths that are multiples of 8 bytes.

More Fragments Bit (M):

Set to 1 for all fragments except the last one.

Helps the receiver know when all fragments have arrived.

This bit is the same for all fragments of a single original datagram.

Identification:

Same for all fragments of a single original datagram.

Used by IPv6 to identify each fragment uniquely.

32 bits in IPv6, larger than IPv4's 16 bits, to support more concurrent fragmented packets.

FRAGMENTABLE VS UNFRAGMENTABLE PART OF A DATAGRAM

Before fragmentation, an IPv6 datagram is divided into two parts:

• Unfragmentable Part: IPv6 header (40 bytes) and all extension headers required by intermediate nodes.

• Fragmentable Part: Remaining extension headers, upper-layer protocol headers (TCP, UDP), payload data, and the first fragment.

Each fragment contains a copy of the unfragmentable part, followed by:

• • A Fragment header

  • A portion of the fragmentable part

I. Fragmentation Process Example

Suppose a datagram has a payload of 3960 bytes, and the path MTU is 1500 bytes (typical Ethernet).

Determine fragment size

• Each fragment must fit into MTU: MTU - IPv6 header (40 bytes) - Fragment header (8 bytes) = 1452 bytes of payload per fragment

• Must be multiple of 8 bytes → 1448 bytes of data per fragment

Create fragments

• Each fragment has a copy of the unfragmentable part

• Each fragment contains a Fragment header with the same Identification value

• IPv6 Payload Length is updated to reflect the fragment size + 8-byte Fragment header

II. Step-by-Step Fragmenting Logic

1. Compute maximum fragmentable payload: The original packet is broken down into IPv6 headers and unfragmentable headers. Then, the maximum possible length of the fragmentable part (MTU - 40 bytes - Fragment header) is computed.

2. Slice the payload into 8-byte multiples: The payload is divided into 8-byte slices. Each slice will contain:

• Unfragmentable part ( copied from the original packet)

• Fragment header (inserted with identification, fragment offset, and M bit)

3. Insert fragment headers for each slice: For each slice, a Fragment header with:

• Identification: unique value

• Fragment Offset: offset of the slice in 8-byte units

• M bit (1 if more fragments, 0 if last fragment) is inserted into the header.

4. Update IPv6 Payload Length: After inserting the Fragment headers, the total length of the fragmented payload is updated.

5. Independent transmission of fragments: Each fragment is transmitted independently, allowing for concurrent transmission and reassembly at the receiver.

III. Reassembling at the Receiver

• Identify all fragments using source and destination addresses: The receiver uses the source address and destination address to identify each fragment.

• Sort fragments by Fragment Offset: The sorted list of fragments is used to concatenate the fragmentable parts in order of their offset.

• Concatenate the fragmentable parts: The sorted fragments are concatenated into a single datagram, with each part containing a copy of the unfragmentable part and a Fragment header.

• Verify the M bit of the last fragment: To ensure complete data, the receiver verifies that the M bit (1 if more fragments) is set for the last fragment.

• Deliver the reassembled datagram to the upper-layer protocol: The completed datagram containing all parts and the correct M bit is delivered to the upper-layer protocol, ensuring that the data has been correctly reconstructed by the recipient.

IV. Practical Example: ICMPv6 Ping

Windows 7 ping example:

Generates an ICMPv6 Echo Request with a 3960-byte payload, comprising 3952 data bytes plus eight ICMP header bytes. 

The Ethernet Maximum Transmission Unit (MTU) is 1500, resulting in the datagram fragmentation into three packets. 

Wireshark reveals a characteristic of fragmented datagram packets – the ‘Next Header’ value is set to 44, indicating a fragment header. 

Specifically, the offset field, when multiplied by 8, precisely calculates the exact byte position within the original datagram – a crucial indicator of where the fragmented data originated.

V. Key Differences Between IPv4 and IPv6 Fragmentation

Advantages in IPv6:

• Routers don’t fragment → faster forwarding

• Larger Identification field → more simultaneous fragmented packets

• Explicit handling reduces accidental fragmentation loops

💡 Visualization Idea:

You can imagine the IPv6 fragmentation like cutting a loaf of bread:

• The loaf = original datagram

• Slices = fragments

• Each slice carries the crust (unfragmentable headers) and a piece of the interior (fragmentable payload)

• Each slice has a label (Fragment header) with offset, M bit, and Identification

• Receiver reconstructs the loaf using the labels

IP forwarding is the process by which hosts and routers decide how to deliver IP datagrams to their destinations. 

While conceptually simple, the details depend on whether the destination is local or remote, and whether the device is acting as a host or a router.

I. Host Forwarding

When a datagram (a small piece of data) needs to reach a destination on the same subnet or directly connected to it, the device simply sends the datagram directly. 

This is because the destination is already within the same network, there’s no need to route it.

Conversely, if the destination is outside the network, the datagram automatically gets sent to a default router. 

II. Router Forwarding

Routers differ from hosts because they forward datagrams not originated locally.

They consult a routing/forwarding table to decide the next hop.

If no route exists → datagram is discarded, and an ICMP error message may be sent back to the source.

III. Routing Table Lookup

IP routers use a process to determine the next hop for a datagram. It starts by checking if the destination IP address matches one of its own IP addresses. 

If it does, the datagram is delivered locally to the correct protocol (like TCP or UDP). 

If the destination isn’t a match, the router then proceeds to use a routing table. 

This table contains information about different networks and routes to different destinations. When the router finds no route, it discards the datagram. 

If the device is in host mode (meaning it’s acting as a server), it might then forward the datagram to a default gateway. 

✅ Key Takeaway

Hosts forward only their own traffic directly, while routers forward traffic for others using routing tables to find the best path.

Essentially, it’s a carefully orchestrated system of delivery that relies on the understanding of network topology and routing protocols. 

The error handling (ICMP messages) is a critical part of this process, ensuring that data gets to the right place, even when things go wrong.

PURPOSE OF A FORWARDING TABLE

A forwarding table (sometimes called a routing table) is a data structure used by a host or router to determine where to send an IP datagram next.

It does not contain the full path to the destination; it only tells the system the next hop along the path.

Forwarding is always hop-by-hop, meaning each router along the path only knows about the next step, not the entire route.

Think of it like giving directions in steps: Go to the next intersection, and at each intersection, a new instruction is given.

The core purpose of a forwarding table is to simplify routing by allowing routers to quickly determine the best path to send data to a destination, even if the destination isn’t explicitly known. 

It’s essentially a pre-configured map of how to reach different networks.

I. Destination (a) – The Heart of the Table

IPv4 (32-bit): This field specifies the network or host the data is destined for. It’s a starting point for the routing process.

Examples:

• 0.0.0.0/0: Indicates the destination is any network. This is the most general route.

• 2001:db8::1/128: Indicates a specific host (2001:db8::1) on a specific network. This is a route to a host within a network.

IPv6 (128-bit): Similar to IPv4, but with a larger address space. It defines a specific address of a host.

Examples: 2001:db8::1/128: A host address.

Purpose: The destination field is the destination network. Routers use this to understand which network to forward the data to.

II. Mask (b) – The Routing Key

• Bitmask Applied to Destination Address: This is the crucial element. The mask is a number that tells the router which part of the destination address to use for routing.

• IPv4 (32 bits): The mask is a 32-bit number that’s multiplied with the destination IP address to determine which portion of the destination address corresponds to the route.

• IPv6 (128 bits): The mask is a 128-bit number that's multiplied with the destination IPv6 address to determine which portion of the destination address corresponds to the route.

• How it works: The mask is applied before the data is considered for the destination address. The router simply uses the mask to know which path to take.

• Example: Let's say we have Destination: 192.168.1.0/24 and the Mask: 255.255.255.0. The router first performs a bitwise AND operation between the mask and the destination address. The result is a number that represents the destination network.

• Importance: This mechanism is key to efficient routing. It allows us to route by network prefixes rather than specific host addresses, making it much easier to manage larger networks.

III. Next-Hop (c) – The Path to the Destination

• IP Address of the Next Router/Host: This is the router that will handle the data once it reaches the destination.

• IPv4 (32 bits): The next hop is the router immediately following the sending router.

• IPv6 (128 bits): The next hop is the router immediately following the sending host.

• Common Role: Often, the next hop is on the same network as the forwarding system. It's a shared prefix – meaning all traffic within that prefix is routed through that router.

• Final Destination: If the destination is the final destination IP, this field contains the destination IP itself.

IV. Interface (d) – The Route Selector

Identifies the outgoing network interface: This tells the router which network connection to use to forward the data.

Examples:

• eth0: Ethernet interface

• wlan0: Wi-Fi interface

• pppoe0: PPP interface

Importance: The interface selection is essential for sending data to the next hop. It’s how the router decides where to send the packet.

V. Preventing Loops (4) – Critical for Stability

Assumption: The router constructs forwarding tables carefully to avoid cycles.

The Goal: Avoid creating loops where a packet gets stuck endlessly and consumes bandwidth.

How it works:

• Each Next Hop Closer: The next hop must be closer to the final destination than the current router.

• Routing Protocol Enforcement: Routing protocols (RIP, OSPF, BGP, IS-IS) are crucial for ensuring that paths are always optimal – that is, they avoid loops.

VI. In Summary

Forwarding tables are a vital component of network routing. 

They allow routers to quickly identify the best path to a destination by intelligently applying masks and selecting the appropriate next hop, all while minimizing wasted bandwidth.

VII. Forwarding Table Example

First entry: default route → send anything unknown to 192.168.1.1

Second entry: local subnet → deliver directly (next hop = 0.0.0.0 means local delivery)

Third entry: route to 10.x.x.x network → send to router at 10.1.1.1

VIII. Key Points

• Forwarding tables are implementation-defined; only conceptual fields are required

• Each router or host only knows the next hop, not the entire path

• Routing protocols maintain table correctness

• Forwarding tables work for IPv4 and IPv6, with field sizes adjusted (32-bit vs 128-bit)

The core of IP forwarding is a process that directs data packets across a network, essentially deciding the best path for each message. Here’s a detailed breakdown of the steps:

I. Examine Destination IP (D):

What it does: The process starts by identifying the destination IP address of the datagram (the address the packet is trying to reach). This is crucial because the destination dictates where the packet needs to go.

Why it’s important: The destination determines the routing information the IP layer needs to use.

II. Search Forwarding Table:

What it does: This is the heart of the process. The IP layer consults a table called the forwarding table. This table contains pre-configured routes for specific destinations.

Search forwarding table for entries where: 

The Key Fields:

• mj (Mask of Entry): The first part of the destination IP address that the IP router knows. It’s a binary mask that specifies the network portion of the IP address.

• dj (Destination Field): The actual destination IP address within the network portion of the mask. This is the data the packet is trying to get to.

• If True → Entry is a Match: If the ‘dj’ matches the ‘mj’, it means the destination IP address is known. The entry is considered a match.

How the table works: The table is organized in a way that prioritizes longest prefixes (the larger number of 1s in the IP address). This helps the router choose the most efficient route.

III. Select Best Match:

What it does: Based on the matching information, the router chooses the entry with the longest prefix length within the matching data.

Why it’s important: The prefix length determines the network the packet needs to traverse. Longer prefixes mean a more complex path.

IV. Use Next-Hop Field (n_k):

What it does: The next-hop field tells the router where to send the datagram after it's been forwarded. It’s the destination IP address on the next hop router.

Why it’s important: It’s the critical step that brings the packet to its destination.

OUTCOMES: WHAT HAPPENS WHEN A MATCH IS FOUND & NOT FOUND

Now let’s look at the different outcomes, which are extremely important for network management.

I. Match Found

Data Forwarded: The datagram is routed to the next hop router. The router now handles the actual delivery of the packet.

Important Note: This is where the application knows the packet is going somewhere.

II. No Match

This is where things get more nuanced and important.

• Local Host Unreachable Error: If the router receives a datagram that’s not routed to its next hop, it’s an error condition. The application needs to be informed to handle it. This is a critical failure.

• On a Router - ICMP Destination Unreachable: The router sends an ICMP (Internet Control Message Protocol) message back to the source (the sender) indicating that the destination is unreachable. This is a standard way of indicating a routing problem.

• If on a Router → ICMP Destination Unreachable Sent Back to Sender: This is a very important case for network routing. The destination IP address is not reachable, so a message is sent back to the sender.

III. Multiple Matches (Important)

Multiple Routes: IP forwarding can sometimes have multiple entries matching the same destination IP address.

OS-Dependent Behavior: The operating system's routing algorithm decides how to handle these multiple matches.

• Simple Systems: The router might just pick the first match.

• Advanced Systems: The router can implement load balancing – distributing the traffic across multiple paths to improve performance and reliability. It can also use split traffic – sending traffic to different routes.

IV. Example

Let's revisit the example:

Forwarding table entries:

• 192.168.0.0/16 → Next hop A

• 192.168.1.0/24 → Next hop B

Destination IP: 192.168.1.45

Matches: Both entries match.

Best Match = /24 (longer prefix).

Datagram Forwarded via Next Hop B.

V. Key Takeaway: IP Forwarding Uses the Longest Prefix

The explanation highlights the key principle: the IP layer chooses the longest prefix match. 

This ensures that the most specific route is selected for the packet, contributing to efficient routing.

In essence, IP forwarding is a mechanism that directs data packets across a network by intelligently choosing the best path based on destination addresses and prefix lengths.

Scenario. We have:

Both hosts are on the same Ethernet network, connected through a switch.

IP datagram originates from S, destined for D.

This is a direct delivery because both hosts are on the same network prefix.

Step 1: Forwarding Table Lookup

The host S checks its forwarding table. 

Let’s assume the table looks like this:

The datagram’s destination address is 10.0.0.9.

Both entries match, but we use the longest prefix match:

• Entry 1: 0 bits match (0.0.0.0/0)

• Entry 2: 25 bits match (10.0.0.0/24) ✅

Decision: Use entry 2 → direct delivery.

• Next Hop: 10.0.0.100 (S’s own interface)

• No intermediate router is needed.

Step 2: Determine Link-Layer Address

IP knows D’s IP address (10.0.0.9), but the switch and Ethernet need D’s MAC address.

If unknown, the host uses ARP (IPv4) or Neighbor Solicitation (IPv6) to map:

Once resolved, the MAC address of D is known.

Step 3: Encapsulate IP Datagram in Frame

IP datagram:

Ethernet frame:

The switch only looks at MAC addresses, not IP addresses.

It forwards the frame to the port connected to D.

Step 4: Delivery

• Frame reaches D

• D strips Ethernet header → sees IP datagram

• IP layer in D processes datagram and delivers it to the upper-layer protocol (TCP/UDP/ICMP).

Result: Successful direct delivery, no routers involved.

✅ Key Points About Direct Delivery

1. Same network prefix → datagram goes directly to target host.

2.  Forwarding table: selects interface and next hop based on longest prefix match.

3. Lower-layer addressing: ARP (IPv4) or Neighbor Discovery (IPv6) resolves MAC addresses.

4. Switches only see MAC addresses, not IP addresses.

5. No intermediate routers are involved.

Scenario. We have:

S wants to send a datagram to 192.48.96.9.

S’s forwarding table has no match for this destination in its local network.

S uses the default route:

The default route tells S: If you don’t know the network, send it to R1.

Step 1: Next-Hop Determination

Since S cannot reach 192.48.96.9 directly, it uses R1 as the next hop.

S needs the MAC address of R1’s interface corresponding to 10.0.0.1.

S uses ARP to resolve:

Once resolved, the Ethernet frame is built: 

The IP datagram inside still has:

Source IP = 10.0.0.100, Destination IP = 192.48.96.9

Important: IP addresses do not change yet. Only the link-layer destination MAC points to R1.

Step 2: Processing at R1

When R1 receives the datagram:

• It looks at the destination IP (192.48.96.9).

• It checks its forwarding table:

No exact match → uses default route (0.0.0.0/0) → next hop is R2 (70.231.159.254).

Network Address Translation (NAT) occurs here:

• Original source IP: 10.0.0.100 (private)

• NAT replaces it with R1’s public IP: 70.231.132.85 (b-side interface)

Why NAT? Private addresses are not routable on the global Internet. NAT makes the packet routable.

Step 3: Forwarding Beyond R1

R1 encapsulates the IP datagram in a new Ethernet frame for the next-hop R2:

Now, the IP datagram looks like:

The IP TTL field decrements at each hop (important for traceroute).

R2 repeats the forwarding steps:

• Receives frame

• Checks destination IP

• Uses default route (or other routes) → forwards to next hop toward destination

• Encapsulates datagram in frame for next hop

NAT only occurs at private → public transition (R1 in this example). Public network routers just forward the packet.

Step 4: Link-Layer vs IP-Layer Forwarding

Key distinction:

• Each hop only needs the next-hop link-layer address, not the full path.

• Routers use forwarding tables + next-hop IP to determine which interface to send the packet to.

This is the essence of indirect delivery: IP addresses are end-to-end, but lower-layer addresses are hop-by-hop.

Step 5: IPv6 Differences

IPv6 is mostly the same conceptually. Differences:

• Neighbor Discovery replaces ARP

• Link-local addresses are used to communicate on the same link (fe80::/10)

• Multiple interfaces may require a scope ID to specify the correct interface

NAT is less common in IPv6 because global unicast addresses are plentiful.

Example:

• %6 = scope ID → tells which interface to use for link-local traffic

• Without scope, Windows errors: No route to destination

Step 6: Traceroute

traceroute shows the path datagrams take to reach a destination. It uses:

• UDP packets with incrementing TTL (Windows: tracert)

• Each router along the path decrements TTL

• If TTL = 0, router replies with ICMP Time Exceeded

• Traceroute records round-trip time (RTT) and next-hop IP

Example output snippet:

Default Routes

• The default route is the most common next hop, used by most hosts and edge routers.

• It sets all unknown traffic to head towards a single gateway IP.

• Simplifies configuration for home users and small networks.

Source and Destination IPs

In the regular internet, source and destination IP addresses remain constant. Exceptions:

• Source routing (rare): occurs when multiple sources send data together.

• NAT (Network Address Translation) modifies source/destination IPs at boundaries.

Link-Layer Headers

Each hop uses a different link-layer header (Ethernet, DSL, Wi-Fi, etc.).

The destination address of each link-layer header points to the next hop. Example:

• Ethernet: ARP resolves next-hop's MAC address.

• IPv6: ICMPv6 Neighbor Discovery resolves next-hop's link-layer address.

Key Takeaways

Default routes simplify forwarding for most hosts, but IP addresses remain constant end-to-end unless NAT or source routing is involved.

Link-layer headers change hop by hop, always pointing to the next hop's address (e.g., ARP for Ethernet, ICMPv6 Neighbor Discovery for IPv6).

ARPs and Neighbor Discoveries are essential for resolving next-hop addresses.

Mobile IP and the problems it solves is the next topic...