IP tunnels are often used for connecting two disjoint IP networks that don't have a native routing path to each other, via an underlying routable protocol across an intermediate transport network. In conjunction with the IPsec protocol they may be used to create a virtual private network between two or more private networks across a public network such as the Internet. Another prominent use is to connect islands of IPv6 installations across the IPv4 Internet.
In IP tunnelling, every IP packet, including addressing information of its source and destination IP networks, is encapsulated within another packet format native to the transit network.
At the borders between the source network and the transit network, as well as the transit network and the destination network, gateways are used that establish the end-points of the IP tunnel across the transit network. Thus, the IP tunnel endpoints become native IP routers that establish a standard IP route between the source and destination networks. Packets traversing these end-points from the transit network are stripped from their transit frame format headers and trailers used in the tunnelling protocol and thus converted into native IP format and injected into the IP stack of the tunnel endpoints. In addition, any other protocol encapsulations used during transit, such as IPsec or Transport Layer Security, are removed.
IP tunneling often bypasses simple firewall rules transparently since the specific nature and addressing of the original datagrams are hidden. Content-control software is usually required to block IP tunnels.
The first specification of IP tunneling was in RFC 1075, which described DVMRP, the first IP multicast routing protocol. Because multicast used special IPv4 addresses, testing DVMRP required a way to get IP datagrams across portions of the Internet that did not yet recognize multicast addresses. This was solved by IP tunneling. The first approach to IP tunneling used an IP Loose Source Route and Record (LSRR) Option to hide the multicast address from the non-multicast aware routers. A multicast-aware destination router would remove the LSRR option from the packet and restore the multicast IP address to the packet's IP destination field. The other approach in the DVMRP specification was IP in IP, as described above. IP in IP soon became the preferred approach, and was later put to use in the Mbone.