RFC 1853

IP in IP Tunneling

📅 published October 1995, from ietf

RFC 1853: IP in IP Tunneling 🎀

Okay bestie, here's the deal with this one 💅 It's from the Network Working Group (Request for Comments: 1853), written by W. Simpson of Daydreamer, dated October 1995. It's Informational, so it's just giving info to the internet community, not a standard. The header doesn't list anything it obsoletes or updates, so it's not stepping on anyone's toes 🫶

Status of this Memo ✨

This memo provides information for the internet community. It does not specify an Internet standard. Distribution of this memo is unlimited, so share away 🦋

IESG Note 🙈

Note that this memo is an individual effort of the author. This document reflects a current informal practice in the internet. There is an effort underway within the IETF Mobile-IP Working Group to provide an appropriate proposed standard to address this issue.

Abstract 💜

This doc talks about implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols.

Table of Contents 🍓

  1.     Introduction ..........................................    2

  2.     Encapsulation .........................................    3

  3.     Tunnel Management .....................................    5
     3.1       Tunnel MTU Discovery ............................    5
     3.2       Congestion ......................................    6
     3.3       Routing Failures ................................    6
     3.4       Other ICMP Messages .............................    6

  SECURITY CONSIDERATIONS ......................................    7
  REFERENCES ...................................................    7
  ACKNOWLEDGEMENTS .............................................    8
  AUTHOR'S ADDRESS .............................................    8

1. Introduction 🌸

Okay so IP-in-IP encapsulation, which uses Protocol/Payload number 4 [RFC-1700], has been bridging parts of the Internet with mismatched capabilities or policies for ages ✨ This doc describes implementation techniques that the Amateur Packet Radio network used for many years to join a big mobile network, and that early IP Security protocol implementations used too.

Using IP in IP encapsulation is different from later tunneling techniques (like protocol numbers 98 [RFC-1241], 94 [IDM91a], 53 [swIPe], and 47 [RFC-1701]). It doesn't insert its own special glue header between IP headers. Instead, the original unadorned IP Header stays put and just gets wrapped in another standard IP header. Iconic, honestly 💖

This info mostly covers IP version 4. Other IP versions will get their own docs.

2. Encapsulation 💅

The encapsulation technique is fairly simple. An outer IP header gets added before the original IP header. In between, you can have any other headers for the path, like security headers specific to the tunnel configuration.

The outer IP header Source and Destination identify the "endpoints" of the tunnel. The inner IP header Source and Destination identify the original sender and recipient of the datagram.

Each header chains to the next using IP Protocol values [RFC-1700].

                                          +---------------------------+
                                          |      Outer IP Header      |
                                          +---------------------------+
                                          |      Tunnel Headers       |
      +---------------------------+       +---------------------------+
      |         IP Header         |       |      Inner IP Header      |
      +---------------------------+ ====> +---------------------------+
      |                           |       |                           |
      |         IP Payload        |       |         IP Payload        |
      |                           |       |                           |
      +---------------------------+       +---------------------------+

The format of IP headers is described in [RFC-791].

Now let's go field by field, because the details matter 🧚

  • Type Of Service: copied from the inner IP header. Optionally, another TOS may be used between cooperating peers.
    • This follows the transparency principle: if the user was expecting a given level of service, then the tunnel should provide the same service. However, some tunnels may be built specifically to provide a different level of service as a matter of policy.
  • Identification: a new number is generated for each outer IP header.
    • The encapsulated datagram may already have been fragmented, and another level of fragmentation may happen because of the tunnel encapsulation. These tunnel fragments get reassembled by the decapsulator, not the final destination.
  • Reserved: ignored (set to zero).
    • This unofficial flag has seen experimental use. While it stays in the inner IP header, it doesn't affect the tunnel.
  • Don't Fragment: copied from the inner IP header. This lets the originator control the level of performance tradeoffs. See "Tunnel MTU Discovery".
  • More Fragments: set as required when fragmenting.
    • This flag isn't copied, for the same reason that a separate Identification is used.
  • Time To Live: the default value specified in the most recent "Assigned Numbers" [RFC-1700]. This makes sure that long, unanticipated tunnels don't interrupt the flow of datagrams between endpoints.
    • The inner TTL is decremented once before encapsulation, and it isn't affected by decapsulation.
  • Protocol: the next header. It's 4 for the inner IP header, when no intervening tunnel headers are in use.
  • Source: an IP address associated with the interface used to send the datagram.
  • Destination: an IP address of the tunnel decapsulator.
  • Options: not copied from the inner IP header. However, new options particular to the path MAY be added.
    • Timestamp, Loose Source Route, Strict Source Route, and Record Route are deliberately hidden within the tunnel. Often, tunnels get built to overcome the inadequacies of these options.
    • Any supported flavors of security options of the inner IP header MAY affect the choice of security options for the tunnel. It isn't expected that there will be a one-to-one mapping of such options to the options or security headers selected for the tunnel.

3. Tunnel Management ⭐

One of the routers along the tunnel interior might run into an error while processing the datagram. That can cause it to return an ICMP [RFC-792] error message to the encapsulator at the IP Source of the tunnel. Unfortunately, ICMP only requires IP routers to return 8 bytes (64 bits) of the datagram beyond the IP header. That's not enough to include the entire encapsulated header 😭 So it's generally not possible for an encapsulating router to immediately reflect an ICMP message from inside a tunnel back to the originating host.

However, by carefully keeping "soft state" about its tunnels, the encapsulator can return accurate ICMP messages in most cases. The router SHOULD maintain at least the following soft state information about each tunnel:

  • Reachability of the end of the tunnel.
  • Congestion of the tunnel.
  • MTU of the tunnel.

The router uses the ICMP messages it receives from the interior of a tunnel to update the soft state information for that tunnel. When later datagrams arrive that would transit the tunnel, the router checks the soft state for the tunnel. If the datagram would violate the state of the tunnel (for example, the MTU is greater than the tunnel MTU when Don't Fragment is set), the router sends an appropriate ICMP error message back to the originator. It also forwards the datagram into the tunnel. Forwarding the datagram despite returning the error message makes sure that changes in tunnel state will be learned.

Using this technique, the ICMP error messages from encapsulating routers won't always match one-to-one with errors found within the tunnel. But they will accurately reflect the state of the network 🫶

3.1. Tunnel MTU Discovery 🦋

When the Don't Fragment bit is set by the originator and copied into the outer IP header, the proper MTU of the tunnel will be learned from ICMP (Type 3 Code 4) "Datagram Too Big" errors reported to the encapsulator. To support originating hosts which use this capability, all implementations MUST support Path MTU Discovery [RFC-1191, RFC-1435] within their tunnels.

As a perk of Tunnel MTU Discovery, any fragmentation that happens because of the size of the encapsulation header is done only once, after encapsulation. This prevents more than one fragmentation of a single datagram, which improves processing efficiency for the path routers and the tunnel decapsulator. Efficient and iconic 👑

3.2. Congestion 🌈

Tunnel soft state will collect indications of congestion, like an ICMP (Type 4) Source Quench in datagrams from the decapsulator (tunnel peer). When forwarding another datagram into the tunnel, it's appropriate to send Source Quench messages to the originator.

3.3. Routing Failures 💀

Because the TTL gets reset each time a datagram is encapsulated, routing loops within a tunnel are especially dangerous when they arrive again at the encapsulator. If the IP Source matches any of its interfaces, an implementation MUST NOT further encapsulate. Instead, the datagram is forwarded normally.

ICMP (Type 11) Time Exceeded messages report routing loops within the tunnel itself. ICMP (Type 3) Destination Unreachable messages report delivery failures to the decapsulator. This soft state MUST be reported to the originator as (Type 3 Code 0) Network Unreachable.

3.4. Other ICMP Messages 🧚

Most ICMP error messages aren't relevant to using the tunnel. In particular, parameter problems are likely to come from misconfiguration of the encapsulator, and they MUST NOT be reported to the originator.

Security Considerations 🔥

Security issues are briefly discussed in this memo. The use of tunneling may obviate some older IP security options (labelling), but it will better support newer IP Security headers. Handle with care, bestie 💜

References ✨

Okay bestie, here's the reading list 📚 every source this doc leans on, with all the details kept exactly as they are:

[IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-based protocols for mobile internetworking", Proceedings of SIGCOMM '91, ACM, September 1991.

[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.

[RFC-1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990.

[RFC-1241] Mills, D., and R. Woodburn, "A Scheme for an Internet Encapsulation Protocol: Version 1", UDEL, July 1991.

[RFC-1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, FTP Software, March 1993.

[RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[RFC-1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.

[swIPe] Ioannidis, J., and Blaze, M., "The Architecture and Implementation of Network-Layer Security Under Unix", Fourth Usenix Security Symposium Proceedings, October 1993.

Acknowledgements 🫶

Huge shoutouts to the people who made this possible 💜

These implementation details of IP Tunneling are mostly derived from independent work done in 1990 by Phil Karn and the TCP-Group hams using KA9Q NOS. Legends 👑

Special thanks to John Ioannidis (then of Columbia University) for the inspiration and experimentation that kicked off this most recent round of IP Mobility and IP Security development 🔥 Some of this text came from [IDM91a] and [swIPe].

The chaining of headers was also described in "Simple Internet Protocol", by Steve Deering (Xerox PARC) 🧚

The overall organization and some of the text came from [RFC-1241], by David Mills (U Delaware) and Robert Woodburn (SAIC) 🌸

Some of the text on tunnel soft state was derived from "IP Address Encapsulation (IPAE)", by Robert E. Gilligan, Erik Nordmark, and Bob Hinden (all of Sun Microsystems) 🦋

Author's Address 🎀

Questions about this memo can also be directed to:

   William Allen Simpson
   Daydreamer
   Computer Systems Consulting Services
   1384 Fontaine
   Madison Heights, Michigan  48071

   Bill.Simpson@um.cc.umich.edu
       bsimpson@MorningStar.com
📦 where this page comes from