IP

Reading time: 8 minute Word count: 1601

Network IP Routing Packet

The packets that go on the road first are not HTTP, TLS, or TCP abstractions. They are individual packets that have to cross subnets, routers, carrier paths, and middleboxes before they can reach the destination host. The first thing that decides whether they can keep moving is not the transport layer or the application layer. It is IP.

IP is often described as a list of address and header fields, but the real high-frequency questions in engineering are different: why a packet was lost, rerouted, fragmented, dropped at one hop, or still could not reach the service even though the service itself was healthy. To answer those questions, the boundaries of IP’s responsibility have to be kept sharp.

IP does not guarantee delivery. It provides unified addressing and forwarding across heterogeneous networks so packets can best-effort move toward the destination; reliability, ordering, and retransmission are left to upper layers

Why It Appears

If every link technology could only communicate inside its own local world, the Internet would never have formed. Different networks needed a shared layer to solve a few things:

A unified address model
Forwarding packets across networks
Letting intermediate devices decide the next hop by destination address
Allowing hosts on different link technologies to join the same larger network

IP solves reachability and forwarding. It does not solve “once it arrives, it must be correct, complete, or ordered.” That is why TCP, UDP, and ICMP all sit on top of it instead of replacing it.

The Background It Came From

IP came from the early Internet protocol stack and was built for internetworking: different hosts, different physical links, different local networks, all needing to join the same larger communication system.

That background determined the design direction:

Prioritize unified addressing and forwarding instead of making the network layer handle reliability
Prioritize interconnecting different networks instead of requiring every link to behave the same way
Prioritize a general forwarding model for routers instead of asking routers to understand application semantics

So IP looks like it does “less” only because its responsibilities were deliberately narrowed.

Grasp the Main Model First

IP can be reduced to three things:

Address: where the packet is going
Routing: which next hop it should take
Best effort: forward if possible, drop if not, and do not promise reliability for the upper layers

One forwarding path can be compressed like this:

Host A
  -> Router 1
    -> Router 2
      -> Router 3
        -> Host B

At each hop, the device usually only cares about two things:

Is the destination directly reachable on this link
If not, who is the next hop

IP does not naturally care whether the application request succeeded, whether the TCP connection retransmitted, or whether the TLS handshake completed. It only cares about getting the packet further along or dropping it when it can no longer move.

The Most Common Main Path

One common IP path can be simplified like this:

sequenceDiagram participant A as Host A participant R1 as Router 1 participant R2 as Router 2 participant R3 as Router 3 participant B as Host B A->>R1: IP Packet(dst=B, TTL=64) R1->>R2: Forward Packet(TTL=63) R2->>B: Forward Packet(TTL=62) B->>R3: Reply Packet(dst=A, TTL=64) R3->>R1: Forward Reply(TTL=63) R1->>A: Forward Reply(TTL=62)

The important thing to notice is not how many devices were crossed. It is that IP repeats the same action at every hop:

Look at the destination address
Consult the route
Decrement TTL
Forward if possible, drop if not

The reply is also a new IP packet. It follows its own routing path hop by hop, and its TTL keeps decreasing as well. The forward and return paths can be the same, or they can differ. If the packet never arrives, the problem may be at any hop, not only at the source and destination.

Why IP Is Best Effort

IP looks “too weak”: it does not guarantee delivery, order, or uniqueness. It seems to do almost nothing. That is exactly why it could scale.

If IP also had to take responsibility for:

End-to-end acknowledgment
Retransmission
Order recovery
Fine-grained congestion control

the state and complexity of intermediate devices would become much larger, and heterogeneous interconnection would be harder to deploy.

IP chooses to shrink itself into best-effort datagram delivery. The tradeoff is that upper layers must compensate:

TCP adds reliability, ordering, and congestion control
UDP keeps a lightweight connectionless model
Applications themselves decide whether to retry, time out, or require idempotency

So IP is not “too weak”. It keeps the network-layer boundary very strict: the network layer only promises reachability.

Why TTL Is So Important

IP packets do not circle the network forever. TTL exists in IPv4 and Hop Limit in IPv6 to prevent routing loops from keeping packets alive indefinitely.

Each hop decrements the value by one. When it reaches zero, the packet is dropped.

That gives operators two useful things:

A safety valve against routing loops
A way to infer path length with tools like traceroute

Without a hop limit, a packet caught in a loop could consume bandwidth forever. With it, the network can fail safely.

Why MTU and Fragmentation Keep Creating Trouble

Different links can carry different maximum frame sizes. That directly affects whether an IP packet can pass through unchanged. This is where MTU problems appear.

If a packet is too large:

It may be fragmented
Or it may be dropped, and the sender has to send smaller packets instead

Fragmentation looks like a rescue mechanism, but in practice it often creates more cost:

More overhead
Higher loss sensitivity
More chances for middleboxes to mishandle the packet
Harder troubleshooting

That is why modern networks prefer to avoid fragmentation when possible and instead rely on path MTU discovery or application-level sizing.

Why Addressing and Routing Must Stay Separate

An IP address is not a permanent geographic location for a machine. It is a logical identifier used for routing decisions. Routers do not forward by “knowing every machine”. They forward by network prefix and routing table.

That means:

Address changes can change the reachability path
One service may have multiple addresses
Whether an address is actually reachable depends not only on the destination host being alive, but also on the path remaining valid

So “can ping” and “business is definitely available” are not the same thing. In the reverse direction, “the business is down” does not necessarily mean the application is wrong. The problem may already be dead at the IP routing layer.

Why TCP Must Sit on Top of IP and Add Reliability

With the boundary above in place, the existence of TCP becomes obvious. IP only promises best-effort forwarding. It does not promise:

That a packet will arrive
That packets will arrive in order
That packets will arrive only once

TCP adds exactly those missing pieces:

Sequence numbers
Acknowledgments
Retransmission
Window control
Congestion control

So IP -> TCP -> HTTP/HTTPS is not an arbitrary stack. Each layer is deliberately adding what the previous layer refused to promise.

What to Look At in Packet Capture

IP packet captures are easy to turn into header-field trivia. A more useful order is below.

First check whether the packet actually left

Confirm:

Whether the source address is reasonable
Whether the destination address is reasonable
Whether the packet is going toward the expected next hop

Many problems never reach “what did the server do?” because the packet already went astray locally or at the first hop.

Then check TTL, ICMP, and path changes

These are usually high-signal observations:

TTL exceeded
Destination unreachable
A hop suddenly disappearing in the middle of the path
Frequent route changes for the same destination

They often point straight at routing, ACLs, middleboxes, or link problems.

Finally check MTU, fragmentation, and loss symptoms

Many “large request hangs, small request works” incidents are really caused by:

MTU mismatch
Fragment loss
A path that does not like large packets

If you only look at HTTP or TCP layers, these can be misread as “the server is slow”.

What Engineering Should Actually Think About IP Today

Do not think of IP as “low-end TCP”. Its job was never reliable transport
Do not treat the address as the host identity. It is first of all an input to routing and reachability
Do not push every network problem up to the application layer. Many problems are already decided at IP when the packet can or cannot keep moving
Do not ignore TTL, ICMP, MTU, and fragmentation. They are often more useful than enumerating header fields
Do not mix up “can connect” with “the path is stable and the performance is normal”. IP reachability is only the start of the chain

IP