4.1 IPv4 Header Architecture and Packet Forwarding

4.1 IPv4 Header Architecture and Packet Forwarding

Quick Answer: The IPv4 header is a structured control block with a minimum size of 20 bytes (IHL = 5) and a maximum of 60 bytes (IHL = 15). Key fields include the 8-bit TTL (decremented at each router hop for loop mitigation), 8-bit Protocol (identifying payloads like ICMP=1, TCP=6, UDP=17, OSPF=89), and 16-bit Header Checksum (recomputed at every hop). When forwarding packets, routers execute a Longest Prefix Match (LPM) in the Forwarding Information Base (FIB) to find the most specific route. Crucially, while transit routers rewrite Layer 2 source and destination MAC addresses at every hop, the Layer 3 source and destination IP addresses remain unaltered.

At the Network Layer (Layer 3) of the TCP/IP protocol suite, the Internet Protocol version 4 (IPv4) provides connectionless, best-effort delivery of data across interconnected networks. While Layer 2 switches switch frames based on physical MAC addresses within a single broadcast domain, Layer 3 routers forward packets across disparate network boundaries. Understanding the internal structure of the IPv4 packet header and the forwarding engine pipeline is essential for mastering Nokia Service Router (SR OS) operations and enterprise routing.

---

Anatomy of the IPv4 Packet Header

Standardized in RFC 791, the IPv4 packet header contains control fields necessary to route, fragment, prioritize, and verify the integrity of network data. The base header without options consists of 20 bytes (160 bits), arranged into 32-bit (4-byte) horizontal words.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |        Header Checksum        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source IP Address                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination IP Address                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (0 to 40 bytes)    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1. Version (4 Bits)

Identifies the version of the IP protocol. For IPv4, this field always contains binary 0100 (decimal 4). If a router receiving the packet does not match this version field with its configured protocol parser, the packet is immediately dropped.

2. Internet Header Length — IHL (4 Bits)

Specifies the total length of the IPv4 header expressed in 32-bit (4-byte) words:

• Because the field is 4 bits wide, its decimal value ranges from 0 to 15 ($2^4 - 1$).
• The minimum valid IPv4 header size is 20 bytes, corresponding to an IHL value of 5 ($5 \times 4 = 20$ bytes).
• Any packet with an IHL value less than 5 is malformed and discarded.
• If IP options are appended, the header length increases up to a maximum IHL value of 15, representing $15 \times 4 = 60$ bytes.

3. Type of Service (ToS) / DiffServ Field (8 Bits)

Historically used to define Quality of Service (QoS) using a 3-bit IP Precedence (IPP) value and 4 Type of Service bits (Delay, Throughput, Reliability, Cost). RFC 2474 modernized this field into the Differentiated Services (DiffServ) architecture:

• DSCP (Differentiated Services Code Point, 6 bits): Provides 64 codepoint values that policy maps to forwarding treatments (0 through 63) for prioritizing packets. Examples include Default Forwarding (DF / CS0 = 0), Expedited Forwarding (EF = 46 for voice traffic), and Assured Forwarding (AF classes for business data).
• ECN (Explicit Congestion Notification, 2 bits): Defined in RFC 3168, allows routers experiencing queue congestion to notify endpoints without dropping packets (00 = Non-ECT, 01/10 = ECN-Capable, 11 = Congestion Encountered).

4. Total Length (16 Bits)

Defines the entire size of the IPv4 datagram in bytes, including both the header and the data payload:

• Being 16 bits wide, the theoretical maximum size of an IPv4 packet is $2^{16} - 1 = 65,535$ bytes.
• The size of the payload alone is calculated by subtracting the header length from the total length: $\text{Payload Bytes} = \text{Total Length} - (\text{IHL} \times 4)$.

5. Identification (16 Bits)

A value used with the source, destination, and protocol to associate fragments of a datagram; it is not a globally unique packet identifier. If a packet must be fragmented to traverse a link with a smaller Maximum Transmission Unit (MTU), each resulting fragment carries this identical Identification value.

6. Flags (3 Bits)

Controls fragmentation behavior across the transit path:

• Bit 0 (Reserved): Must always be set to 0.
• Bit 1 — DF (Don't Fragment): When set to 1, informs intermediate routers that the packet must never be fragmented. If a router cannot forward the packet because its Total Length exceeds the outgoing link's MTU, the router drops the packet and returns an ICMP Destination Unreachable (Type 3, Code 4: Fragmentation Needed and DF Set) message to the sender. This mechanism forms the foundation of Path MTU Discovery (PMTUD).
• Bit 2 — MF (More Fragments): Set to 1 on all fragmented packets except the final fragment, which has MF set to 0. An unfragmented packet has MF set to 0.

7. Fragment Offset (13 Bits)

Indicates the relative position of the fragment's payload within the original unfragmented datagram, measured in 8-byte (64-bit) blocks:

• The first fragment has an offset of 0.
• A subsequent fragment with an offset of 100 actually begins at byte position $100 \times 8 = 800$ of the original payload.
• The receiving destination host uses the Identification, Flags (MF), and Fragment Offset fields to reassemble fragments in proper sequence.

8. Time to Live — TTL (8 Bits)

A hop counter designed to prevent packets from circulating indefinitely in routing loops:

• Initialized by the source host (common defaults are 64, 128, or 255).
• Every transit router that processes and forwards the packet must decrement the TTL value by at least 1 (or the number of seconds the packet queued inside the router, though in modern line-rate forwarding it is always decremented by 1).
• If a router decrements the TTL to 0, the packet is dropped immediately. The router then generates and transmits an ICMP Time Exceeded (Type 11, Code 0) message back to the source IP address.

9. Protocol (8 Bits)

Identifies the upper-layer protocol or application layer carried inside the IPv4 payload. When the destination host or router receives the packet, the Protocol field instructs the network stack which protocol driver should process the encapsulated payload:

10. Header Checksum (16 Bits)

Provides error detection strictly for the IPv4 header (it does not protect the payload, which relies on Layer 4 TCP/UDP checksums or Layer 2 Ethernet CRC):

• Calculated as the 16-bit one's complement of the one's complement sum of all 16-bit words in the header.
• Crucial Forwarding Detail: Because every transit router decrements the TTL field by 1, the IPv4 header contents change at every single hop. Consequently, every router along the transit path must verify the checksum upon arrival, decrement the TTL, and recompute a new Header Checksum before forwarding the packet out an egress interface.

11. Source and Destination IP Addresses (32 Bits Each)

Specifies the 32-bit IPv4 address of the originating sender and the intended recipient node.

12. Options and Padding (0 to 40 Bytes)

Optional fields used for diagnostic or security purposes (such as Record Route, Strict Source Routing, Loose Source Routing, or Timestamp). Because the IPv4 header must end on a 32-bit boundary, zero-value Padding bits are appended to guarantee that the total header length is an exact multiple of 4 bytes.

---

Longest Prefix Match (LPM) Routing Lookup

When an IP packet arrives at a router, the router's forwarding engine must determine where to send it. It extracts the packet's destination IP address and queries the Forwarding Information Base (FIB).

The Longest Prefix Match Principle

A modern router's FIB may contain hundreds of thousands of network routes learned from static configurations, direct interfaces, and dynamic routing protocols (such as OSPF, IS-IS, and BGP). Frequently, a single destination IP matches multiple overlapping routing prefixes.

The universal rule governing IP route selection is Longest Prefix Match (LPM):

When multiple routing entries in the forwarding table match a packet's destination IP address, the router must select the route with the longest prefix length (the largest number of matching mask bits, or highest /n value). The most specific route always wins.

Worked Example: Forwarding with Overlapping Prefixes

Consider a router possessing the following five active routes in its FIB:

1. Route A: 0.0.0.0/0 via Next-Hop 198.51.100.1 (Default Route)
2. Route B: 10.0.0.0/8 via Next-Hop 192.0.2.1
3. Route C: 10.20.0.0/16 via Next-Hop 192.0.2.5
4. Route D: 10.20.30.0/24 via Next-Hop 192.0.2.9
5. Route E: 10.20.30.64/28 via Next-Hop 192.0.2.13

Suppose the router receives three successive packets:

• Packet 1 Destined to 10.20.30.70:

  • Matches Route A (/0)
  • Matches Route B (/8)
  • Matches Route C (/16)
  • Matches Route D (/24)
  • Matches Route E (/28: range 10.20.30.64 to 10.20.30.79)
  • Decision: The router forwards Packet 1 to Next-Hop 192.0.2.13 because Route E has the longest prefix (/28 = 28 matching bits).

• Packet 2 Destined to 10.20.30.150:

  • Matches Route A (/0), Route B (/8), Route C (/16), and Route D (/24).
  • Does not match Route E (.150 is outside .64–.79).
  • Decision: The router forwards Packet 2 to Next-Hop 192.0.2.9 via Route D (/24).

• Packet 3 Destined to 192.168.5.1:

  • Does not match Routes B, C, D, or E.
  • Matches only Route A (0.0.0.0/0).
  • Decision: Forwarded to the default gateway Next-Hop 198.51.100.1.

Exam Tip: Administrative Distance (or Route Preference in Nokia SR OS) is used only when competing routing protocols offer the exact same prefix and mask to determine which route enters the Routing Information Base (RIB). Once routes are programmed into the FIB, prefix length (/n) is the sole criteria for LPM. A /28 route with a high preference will always beat a /24 route with a low preference for matching traffic.

The Default Route (0.0.0.0/0)

The prefix 0.0.0.0/0 (mask 0.0.0.0) has a prefix length of zero bits. Because it requires zero bits to match, it matches every possible IPv4 address. It serves as the "gateway of last resort." If a packet arrives and matches no specific network prefix in the FIB, and a default route exists, it is sent to the default route's next hop. If no default route is configured and no specific prefix matches, the packet is discarded, and an ICMP Destination Network Unreachable (Type 3, Code 0) is returned to the sender.

---

Step-by-Step Router Forwarding Engine Workflow

In Nokia Service Routers (such as the 7750 SR equipped with FP4 or FP5 network processing silicon), packet forwarding occurs entirely in hardware at wire speed within the Data Plane. The following seven-step model explains ordinary Ethernet/IPv4 unicast forwarding. Hardware may pipeline or reorder operations. ICMP responses depend on suppression rules, configuration, rate limits, and a working return path:

+---------------------------------------------------------------------------------------------------+
|                                 ROUTER FORWARDING PIPELINE                                        |
+---------------------------------------------------------------------------------------------------+
| [1] Ingress L2 Validation  --> Check Ethernet FCS / CRC; strip L2 frame header                     |
| [2] L3 Integrity Check     --> Verify Version=4, IHL >= 5, recompute and verify IPv4 Checksum     |
| [3] TTL Inspection         --> Check TTL. If TTL <= 1, drop & send ICMP Type 11; else TTL = TTL - 1|
| [4] FIB LPM Route Lookup   --> Match Destination IP against FIB; find Next-Hop IP & Egress Port   |
| [5] L2 Next-Hop Resolution --> Query ARP Cache for Next-Hop MAC address                           |
| [6] L2 Rewrite & Checksum  --> Prepend new Source/Dest MAC; recalculate IPv4 Header Checksum       |
| [7] Egress Transmission    --> Calculate new Ethernet FCS; serialize frame out physical port      |
+---------------------------------------------------------------------------------------------------+

Step 1: Ingress Layer 2 Frame Reception and Validation

The physical port receives the electrical, optical, or radio bitstream. The Media Access Control (MAC) layer checks the Ethernet Frame Check Sequence (FCS) for transmission errors. If the FCS is corrupt, the frame is dropped. If valid, the router verifies that the destination MAC is the router interface's own MAC address (or a multicast/broadcast address). The Layer 2 Ethernet header is then stripped, passing the decapsulated IPv4 datagram to the Layer 3 processing engine.

Step 2: Layer 3 Header Integrity Verification

The router inspects the IPv4 header fields:

1. Verifies that the Version field equals 4.
2. Verifies that the IHL is 5 or greater.
3. Checks the 16-bit Header Checksum against the received header bytes. If corruption occurred in transit, the packet is dropped silently.

Step 3: TTL Decrement and Expiration Handling

The router checks the incoming 8-bit TTL field:

• If the TTL is 1 or 0, the packet cannot be forwarded further. The router drops the packet and dispatches an exception packet to the Control Processing Module (CPM) to transmit an ICMP Time Exceeded (Type 11, Code 0) message back to the packet's source IP address.
• If the TTL is greater than 1, the forwarding engine decrements the TTL by 1 ($TTL_{\text{new}} = TTL_{\text{old}} - 1$).

Step 4: FIB Longest Prefix Match (LPM) Lookup

The forwarding hardware extracts the 32-bit Destination IP address and performs a search across the FIB. The search returns:

1. The Egress Interface (the physical port, LAG, or VLAN sub-interface).
2. The Next-Hop IP Address (either an adjacent router's interface IP, or the target host itself if the subnet is directly connected).

Step 5: Next-Hop Layer 2 Address Resolution

To transmit the packet across the next Layer 2 segment, the router must know the destination Layer 2 physical address corresponding to the next-hop IP:

• The router queries its local ARP Cache Table.
• If an ARP entry exists for the next-hop IP, the hardware retrieves the associated 48-bit MAC address.
• If no ARP entry exists, the router initiates an ARP Request and may queue a limited number of packets or drop traffic while resolution is pending on the local segment to resolve the next-hop MAC.

Step 6: Layer 2 Header Rewrite and IPv4 Checksum Recalculation

The router prepares the packet for transmission onto the egress link:

1. Layer 2 Header Rewrite: The router constructs an entirely new Ethernet frame header:
   • Source MAC: Becomes the MAC address of the router's egress interface.
   • Destination MAC: Becomes the MAC address of the next-hop device (retrieved from the ARP table).
   • EtherType: Set to 0x0800 (IPv4).
2. IPv4 Header Checksum Recalculation: Because the TTL field was decremented in Step 3, the router recomputes the new 16-bit IPv4 Header Checksum.

Step 7: Frame Egress and Physical Transmission

The newly encapsulated frame is queued in the egress traffic manager (applying Quality of Service shaping and scheduling). Finally, a new 32-bit Ethernet CRC/FCS is computed and appended to the frame trailer, and the frame is transmitted onto the physical transmission medium.

---

The Immutability of Layer 3 vs The Transience of Layer 2

A fundamental concept tested in the Nokia NRS I exam is how Layer 2 and Layer 3 addressing behave across multi-hop transit paths:

Unless a router explicitly performs Network Address Translation (NAT), Layer 3 Source and Destination IP addresses never change from the moment the packet leaves the sending node until it reaches the final recipient. In contrast, Layer 2 Source and Destination MAC addresses are rewritten at every single router hop along the path.

Primary technical reference

Specification or Nokia manual, checked October 20, 2026. Examples are teaching scenarios, not captured router execution.