How IP-in-IP Tunneling Works: The Foundation of Connectivity

What IP-in-IP Tunneling Actually Does

When you need to move IP traffic between two networks that cannot route to each other directly—because the path between them uses a different addressing scheme, or because you need to preserve the original source and destination addresses intact—IP-in-IP tunneling is often the cleanest solution. It wraps an entire IP packet inside a new outer IP packet, adds no encryption overhead, and relies on no protocol more exotic than IP itself.

Standardized in RFC 2003, IP-in-IP is assigned IP Protocol number 4. Routers in the transit path see only the outer IP header and route the packet normally. At the far end of the tunnel, the receiving endpoint strips the outer header and delivers the original inner packet to its final destination as though no tunneling occurred.

This simplicity is the defining characteristic of IP-in-IP. There are no keys to manage, no encryption algorithms to negotiate, and no session state to maintain. The only requirement is that both tunnel endpoints can reach each other over the underlying IP network.

How IP-in-IP Encapsulation Works

The mechanics follow a precise sequence at both the ingress (entry) and egress (exit) tunnel endpoints:

1. Packet arrival at ingress: A standard IP packet arrives at the tunnel interface with its original source address (for example, 10.1.0.5) and its original destination (for example, 10.2.0.8). The routing table on the ingress router matches a route that sends traffic into the tunnel.
2. Outer header construction: The ingress router prepends a new IP header. The outer source address is the IP of the ingress tunnel endpoint, and the outer destination is the IP of the egress tunnel endpoint. The Protocol field in the outer header is set to 4, identifying the payload as another IP packet.
3. Transit routing: Every router between the two endpoints processes only the outer header. They have no knowledge of the inner packet. The encapsulated datagram follows the normal routing path across the internet or the provider backbone.
4. Decapsulation at egress: The egress endpoint receives the packet, recognizes Protocol 4, removes the outer header, and forwards the inner packet based on its original destination address.

The overhead introduced is exactly 20 bytes—the size of one minimal IPv4 header. On a 1,500-byte Ethernet frame, this leaves a maximum inner payload of 1,480 bytes, which means the Maximum Transmission Unit (MTU) of the inner network is reduced by 20 bytes. This is a small and fixed cost compared to tunneling protocols that add variable-length headers or per-packet encryption state.

Architecture and Tunnel Components

A working IP-in-IP deployment has three logical components:

• Ingress tunnel endpoint: The device that performs encapsulation. On Linux, this is typically a tunl0 or named ipip interface created with ip tunnel add. On Cisco IOS, it is a tunnel interface with tunnel mode ipip.
• Transit network: The path between the two endpoints. This can be any IP network, including the public internet. The transit routers need no special configuration—they see only standard IP packets.
• Egress tunnel endpoint: The device that decapsulates. It must be configured to accept packets with Protocol 4 and must have a route for the inner address space pointing toward the appropriate local interface.

On Linux, a minimal IP-in-IP tunnel is configured as follows:

ip tunnel add ipip0 mode ipip remote 203.0.113.2 local 198.51.100.1
ip link set ipip0 up
ip route add 10.2.0.0/24 dev ipip0

On the far side, the mirror configuration references the reversed addresses. No daemon, no certificate, no pre-shared key—just two interface configurations and a route.

Real-World Use Cases

Mobile IP (RFC 3344): When a device moves between networks—say, from one cellular base station to another—it needs to maintain the same IP address so active sessions (TCP connections, VoIP calls) are not interrupted. A home agent at the original network encapsulates traffic destined for the mobile's home address inside an IP-in-IP tunnel and forwards it to the device's current location (the care-of address). The device decapsulates the packet and presents it to the application layer with the original destination intact.

Overlay networks and container networking: Kubernetes clusters that use the Calico or Flannel CNI plugins optionally use IP-in-IP to encapsulate pod traffic crossing node boundaries. Each node is an IP-in-IP tunnel endpoint, and pod traffic is wrapped in a new header using the node's IP. This allows pod subnets to communicate without requiring the underlying network infrastructure to know about pod addressing.

Traffic engineering and policy routing: Network operators sometimes use IP-in-IP to steer traffic through a specific path—a particular security appliance or a measurement point—without altering routing tables throughout the infrastructure. The outer header determines the path; the inner header preserves the original flow metadata.

Multicast over unicast backbones: IP-in-IP is used in the PIM (Protocol Independent Multicast) register process to carry initial multicast packets from the first-hop router to the rendezvous point as encapsulated unicast. This is a defined part of PIM-SM behavior in RFC 7761.

IP-in-IP vs Other Tunneling Protocols

Common Misconceptions

IP-in-IP provides privacy or encryption

It does not. IP-in-IP is purely a transport mechanism. The inner packet's contents are completely visible to anyone with access to the transit path. If you need encryption, you must layer IPsec on top or use a different protocol entirely. Using IP-in-IP as a substitute for a VPN is a configuration error that exposes inner traffic in plaintext.

IP-in-IP only works with IPv4

While RFC 2003 specifically covers IPv4-in-IPv4 encapsulation, there are related standards for other combinations. RFC 2473 covers generic packet tunneling in IPv6, which includes IPv4-in-IPv6 and IPv6-in-IPv6. Linux supports all these modes through the ip6tnl and sit (Simple Internet Transition) tunnel interfaces.

IP-in-IP requires static routing everywhere

Only the tunnel endpoints need to know about the tunnel. The transit routers require no special configuration. You can run OSPF, BGP, or any other routing protocol on top of IP-in-IP tunnels to distribute routes dynamically, just as you would over any point-to-point link.

GRE is always the better choice

GRE is more versatile, but versatility has a cost. If your use case is purely IP-to-IP forwarding with no need to carry non-IP protocols and no need for the GRE key or sequence number fields, IP-in-IP produces less overhead per packet and is simpler to reason about in packet captures. For high-throughput paths—10 Gbps and above—the 4-byte difference between GRE and IP-in-IP headers can matter at line rate.

Pro Tips for IP-in-IP Deployments

• Account for MTU reduction immediately. The 20-byte outer header reduces the usable MTU. Set the MTU on the tunnel interface to 1480 (for Ethernet links with 1500-byte MTU) and configure Path MTU Discovery or MSS clamping to prevent fragmentation inside the tunnel.
• Apply ingress filtering on decap endpoints. Accept Protocol 4 packets only from known peer addresses. An open IP-in-IP endpoint can be abused to bypass firewall rules by tunneling packets through your decapsulation node.
• Use a loopback as the tunnel source. Binding the tunnel source to a loopback interface rather than a physical interface means the tunnel stays up even if the primary physical interface goes down and traffic reroutes through a backup path.
• Monitor with ICMP Type 3 Code 4 messages. Path MTU Discovery relies on ICMP unreachable messages. If your transit network filters ICMP, inner connections will black-hole at MTU boundaries. Always verify ICMP pass-through on your tunnel path.
• Avoid recursive encapsulation. If you accidentally route the outer tunnel traffic back through the tunnel interface, you get nested encapsulation that grows until the packet is dropped. Verify your routing table ensures outer tunnel traffic exits via the physical interface, not the tunnel interface itself.
• Document your tunnel pairs carefully. IP-in-IP tunnels are stateless and produce no log entries when established. The only way to know they exist is from interface and routing configurations. Undocumented tunnels become security blind spots in firewall audits.

IP-in-IP tunneling remains one of the most efficient transport mechanisms available precisely because it solves a single problem and solves it completely. When your requirement is to move IP packets across a network that cannot natively route them, and you do not need encryption, IP-in-IP delivers that with the minimum possible overhead. Check your public IP address and tunnel endpoint details here.