IP tunnel
An IP tunnel, also known as IP in IP tunneling, is a networking technique that encapsulates an original IP packet (the payload) within a new outer IP packet (the tunnel header) to transport it across an intermediate IP network, effectively creating a virtual point-to-point link between endpoints while hiding the inner packet's details from intermediate routers.[1] This encapsulation uses the IP protocol number 4 for IPv4 or equivalent mechanisms for IPv6, allowing the outer header to route the packet to the tunnel endpoint where the inner packet is decapsulated and forwarded to its final destination.[1] IP tunnels serve multiple purposes in modern networks, including enabling the transition from IPv4 to IPv6 by carrying IPv6 packets over IPv4 infrastructure, connecting disjoint or remote networks such as in mobile or satellite environments, and providing a foundation for secure communications through integration with protocols like IPsec.[2] [3] For instance, they facilitate virtual private networks (VPNs) by simulating direct connections over public IP networks, bypassing limitations of physical topology. Common implementations include automatic tunneling for IPv6 transition and manual tunnels for specific enterprise needs.[2] Despite their utility, IP tunnels introduce architectural considerations, such as maximum transmission unit (MTU) fragmentation risks and potential security vulnerabilities like traffic obfuscation that can evade monitoring or amplify denial-of-service attacks if not properly secured.[4] In terms of differentiated services, tunnels can operate in a "pipe model" to preserve inner packet markings for end-to-end quality of service or a "uniform model" to treat the tunnel as part of the path, influencing how traffic is prioritized across domains.[5] Management of IP tunnels is standardized through MIB modules for monitoring and configuration over IPv4 and IPv6 networks.[6]Overview
Definition and Basics
An IP tunnel is a networking technique that encapsulates an original IP packet, referred to as the payload or inner packet, within another IP packet known as the carrier or outer packet, thereby creating a virtual point-to-point connection over an intervening network. This encapsulation uses the IP protocol number 4 for IPv4-in-IPv4 or 41 for IPv6-in-IPv4 in the outer header.[7][8] This process allows the inner packet to traverse networks that may otherwise be incompatible with or restrict the original traffic, treating the tunnel as a logical link between endpoints.[4] Key terminology in IP tunneling includes the tunnel endpoints, which consist of the ingress point where encapsulation occurs—adding the outer IP header to the inner packet—and the egress point where decapsulation takes place, stripping the outer header to forward the original inner packet.[4] The inner header carries the source and destination addresses of the original communication, while the outer header provides routing information for transit across the tunnel path; decapsulation ensures the inner packet is restored intact at the egress for delivery to its final destination.[8] IP tunneling operates specifically at the network layer (Layer 3 of the OSI model), distinguishing it from tunneling at lower layers like the data link layer (e.g., Ethernet encapsulation) or higher layers such as the application layer, where protocols would wrap non-IP payloads or handle user-level data differently.[4]Primary Purposes
IP tunnels primarily enable the connection of otherwise incompatible or disjoint networks, such as carrying packets across intervening infrastructure that does not directly support the inner protocol, thereby addressing challenges in heterogeneous or segmented environments.[9] This capability allows isolated endpoints to communicate effectively.[10] Another core purpose is to extend network reach, permitting the logical connection of remote sites or disjoint IP domains over underlying infrastructure, thereby creating virtual links that simulate direct adjacency.[10] IP tunnels also support protocol transitions, such as carrying IPv6 traffic within IPv4 packets during the migration from IPv4 to IPv6, ensuring compatibility between evolving network standards without immediate full infrastructure upgrades.[2] IP tunnels provide a foundation for secure communications, serving as a basis for integrating encryption and authentication protocols like IPsec to safeguard transmissions over untrusted public networks.[2] On the performance front, tunnels facilitate the aggregation of traffic flows, which can optimize routing efficiency and reduce protocol overhead in scenarios requiring consolidated bandwidth management.[11] In practice, organizations often employ IP tunnels to interconnect branch offices across the public internet, eliminating the need for costly dedicated lines while maintaining seamless data exchange between locations.[12]Technical Fundamentals
Encapsulation Mechanism
In IP tunneling, the encapsulation mechanism involves wrapping an original (inner) IP packet within a new (outer) IP packet to transport it across an intermediate network that may not support the inner packet's protocol or addressing. At the ingress tunnel endpoint, the process begins by decrementing the Time to Live (TTL) field in the inner IP header by one, as if it were being forwarded normally. An outer IP header is then prepended to the inner packet, with the outer header's source address set to the ingress endpoint's address and the destination address set to the egress endpoint's address. The outer header's Protocol field is typically set to 4 for IP-in-IP encapsulation, indicating that the payload is another IP packet, though other values may be used depending on additional tunnel headers. For IPv6 outer headers, the Next Header field is set to 41 for IPv6 encapsulation. Optionally, intermediate protocol headers—such as those for Generic Routing Encapsulation (GRE) or security protocols—can be inserted between the outer IP header and the inner packet to provide features like multiplexing or authentication, increasing the overall header length. The outer header's Total Length field is updated to reflect the size of the entire encapsulated datagram, its Header Checksum is recalculated, and other fields like Type of Service (TOS) are often copied from the inner header for consistency. This results in the inner packet being treated as opaque payload by the outer network's routers, which forward it based solely on the outer header.[13][1] The decapsulation process occurs at the egress tunnel endpoint, where the outer IP header (and any optional intermediate headers) is stripped away upon receipt of the tunneled packet. The inner IP header is then inspected, and its TTL is not further decremented during this step to avoid double-counting the tunnel traversal. If the inner TTL has reached zero, the packet is discarded with an ICMP Time Exceeded message generated if applicable. The decapsulated inner packet is subsequently forwarded to its original destination as a standard IP datagram, using the inner header's routing information. This endpoint-based processing ensures that the tunnel remains transparent to the endpoints of the original communication.[13][1] Encapsulation introduces overhead by adding 20 bytes for a basic IPv4 outer header, or up to 60 bytes when including optional headers like IPv6 outer headers or GRE, which expands the total packet size and can necessitate adjustments to the Maximum Transmission Unit (MTU). To mitigate this, tunnel endpoints often use Path MTU Discovery, where the effective MTU is reduced by the overhead amount (e.g., subtracting 20-40 bytes for IPv4/IPv6 headers), preventing excessive fragmentation along the path. If the encapsulated packet exceeds the path MTU, the ingress endpoint may fragment the inner packet before encapsulation or set the Don't Fragment bit in the outer header to trigger ICMP feedback for dynamic MTU adjustment.[1][14] Error handling in IP tunneling distinguishes between the outer and inner headers to maintain integrity across the tunnel. The outer IP header includes its own checksum, which is verified by intermediate routers and the egress endpoint to detect transmission errors in the tunnel path; if invalid, the entire packet is dropped, and an ICMP message may be sent to the ingress endpoint. The inner packet's checksum remains unchanged and is only validated post-decapsulation, preserving end-to-end error detection. Fragmentation issues arise if the inner packet is larger than the tunnel MTU, potentially leading to reassembly at the egress endpoint, which can introduce delays or packet loss if fragments are dropped; thus, protocols recommend avoiding fragmentation by preferring smaller inner packets or enabling Path MTU Discovery to signal reductions proactively.[13][1]Header Structure and Processing
In IP tunneling, the outer IP header encapsulates the original packet, using the IP addresses of the tunnel endpoints as source and destination to route the tunneled traffic across the network.[13] The outer header's protocol field specifies the tunneling mechanism, such as IP protocol number 4 for IP-in-IP encapsulation or 47 for Generic Routing Encapsulation (GRE).[13][15] Other fields, like the Type of Service (TOS), may be copied from the inner header to preserve quality-of-service markings, while the total length reflects the entire encapsulated datagram, and the Time to Live (TTL) is set to ensure delivery to the egress endpoint.[13] The inner IP header, which carries the original packet's source and destination addresses, remains largely preserved during transit to maintain the integrity of the end-to-end routing information.[13] It is typically unchanged except for the TTL having been decremented at the ingress endpoint to account for the tunnel traversal as a single logical hop, preventing excessive decrementing that could occur if treated as multiple router hops.[13] IP options from the inner header are not copied to the outer header, which can affect processing for features like source routing or timestamps.[13] At the ingress endpoint, the encapsulator adds the outer IP header to the inner packet (following the encapsulation mechanism of wrapping the original datagram as payload) and forwards it based on the outer destination address toward the egress endpoint.[13] Intermediate routers along the path process the packet as standard IP traffic, examining only the outer header for routing decisions and decrementing the outer TTL without awareness of the encapsulated content.[13] Upon arrival at the egress endpoint, the outer header and any tunnel-specific headers are stripped, and the inner packet is forwarded based on its original destination address, with checks to ensure the TTL allows continued delivery.[13] Key challenges in header processing include preventing recursive tunneling, where a tunneled packet is erroneously re-encapsulated, potentially causing loops; implementations address this by discarding packets at the encapsulator if the inner source address matches the local interface or if the outer destination is the same device.[13] Handling IP options poses another issue, as their exclusion from the outer header may bypass security filters or complicate path MTU discovery, requiring careful configuration to avoid fragmentation or drops.[13]Common Protocols and Types
Generic Routing Encapsulation (GRE)
Generic Routing Encapsulation (GRE) is a tunneling protocol that enables the encapsulation of a wide variety of network layer protocols inside virtual point-to-point links over an IP network. Defined in RFC 2784, GRE provides a lightweight mechanism for transporting arbitrary payload packets by wrapping them in a GRE header and an outer IP header, using IP protocol number 47 to identify GRE packets in IPv4 networks.[16] This design allows GRE to support multiprotocol encapsulation without relying on encryption, making it suitable for scenarios where routing flexibility is prioritized over security. An extension in RFC 2890 adds optional fields to the GRE header for enhanced functionality in traffic identification and ordering.[17] The GRE header consists of a fixed portion followed by optional fields, ensuring minimal overhead for basic operations. The fixed header consists of a 2-octet Flags and Version field (with bits 13-15 set to 0 for the version) followed by a 2-octet Protocol Type field that specifies the encapsulated protocol (e.g., 0x0800 for IPv4 or 0x809B for IPX). The Flags field includes specific bits for optional elements: checksum (bit 0), reserved (bit 1), key (bit 2, per RFC 2890), and sequence number (bit 3, per RFC 2890); the remaining bits are reserved and must be zero.[16][17] Optional fields include a 2-octet Checksum and 2-octet Reserved1 if the checksum bit is set, a 4-octet Key for flow identification to demultiplex traffic in shared tunnels, and a 4-octet Sequence Number for maintaining packet order by incrementing per flow and discarding out-of-sequence packets at the receiver.[17] This structure supports multiprotocol payloads by relying on the Protocol Type to route the inner packet appropriately after decapsulation. GRE excels in use cases involving non-IP protocols and multicast traffic, where native IP networks may lack support. It enables the tunneling of legacy protocols such as IPX or AppleTalk over modern IP infrastructures, preserving their headers intact for end-to-end delivery without requiring protocol-specific adaptations.[12] Additionally, GRE natively handles IP multicast and broadcast packets, facilitating dynamic routing protocol exchanges like OSPF or EIGRP across tunnels that would otherwise be restricted in unicast-only environments. Configuring a basic GRE tunnel on Cisco routers involves creating a virtual tunnel interface and specifying endpoints, without any encryption parameters. The process starts with entering global configuration mode and creating the interface usinginterface Tunnel <number>, followed by assigning an IP address with ip address <ip> <mask>. The tunnel source is set via tunnel source <local-ip-or-interface>, and the destination with tunnel destination <remote-ip>, establishing the point-to-point link. Routing is then enabled on the tunnel interface to forward traffic, such as with ip route statements or dynamic protocols, allowing encapsulated packets to traverse the IP network seamlessly.