RFC 2003

IP Encapsulation within IP

📅 published October 1996, from ietf

RFC 2003: IP Encapsulation within IP 🎀

Okay bestie, let's start with the ID card 💅 This is RFC 2003, called IP Encapsulation within IP, written by C. Perkins at IBM, dated October 1996. It's filed under the Standards Track category, which makes it an official Internet standards track protocol 🔥 Its header doesn't list anything it obsoletes or updates, so it's standing completely on its own ✨

Status of This Memo 🌸

This document is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited, so share it with whoever 💜

Abstract 🦋

This document explains how an IP datagram can be encapsulated, which just means carried as the payload inside another IP datagram. Encapsulation is a way to change the normal IP routing for a datagram. Instead of going where the network part of the original Destination Address field points, it gets delivered to an intermediate destination first ✨ That's giving detour energy. Encapsulation can serve lots of purposes, like getting a datagram to a mobile node using Mobile IP 🧚

1. Introduction 🍓

Okay, so this doc is all about wrapping an IP datagram up as payload inside another IP datagram 🎁 The reason you'd do it is to change the usual IP routing. The datagram gets sent to an intermediate destination that the network part of the original Destination Address wouldn't have picked on its own 🙈 Once the encapsulated datagram reaches that middle node, it gets decapsulated, which means unwrapped. You get the original IP datagram back, and it's delivered to whoever the original Destination Address field names 💖 People call this "tunneling" the datagram, and the encapsulator and decapsulator are the "endpoints" of the tunnel. Iconic naming, honestly 🌈

In the most general tunneling case, the path looks like this:

source ---> encapsulator --------> decapsulator ---> destination

The source, encapsulator, decapsulator, and destination are all separate nodes. The encapsulator is the "entry point" of the tunnel, and the decapsulator is the "exit point" ✨ Multiple source-destination pairs can share the same tunnel between the encapsulator and decapsulator, which is so efficient, no cap 💅

2. Motivation 👑

The Mobile IP working group decided to use encapsulation to get datagrams from a mobile node's "home network" over to an agent. That agent can then deliver them locally, by normal means, to the mobile node wherever it is right now, away from home [8] 🧳 Encapsulation is also useful whenever the source, or an intermediate router, of an IP datagram needs to influence the route the datagram takes to its ultimate destination 🗺️ Other possible uses include multicasting, preferential billing, picking routes with selected security attributes, and general policy routing 💜

Here's the thing: encapsulation and the IP loose source routing option [10] can be used in similar ways to affect a datagram's routing 👀 But there are several technical reasons to prefer encapsulation, and they're kind of a big deal:

  • There are unsolved security problems with the IP source routing options 💀
  • Current Internet routers have performance problems when they forward datagrams that contain IP options, including the IP source routing options 🐢
  • Lots of current Internet nodes process IP source routing options incorrectly 😭
  • Firewalls may exclude IP source-routed datagrams 🧱
  • Inserting an IP source route option can complicate how the source and/or destination process authentication information, depending on how that authentication is specified to work 🔐
  • It's considered impolite for intermediate routers to modify datagrams they didn't originate 🙅‍♀️

Those technical advantages have to be weighed against the disadvantages of encapsulation too 🎀

  • Encapsulated datagrams are typically larger than source routed datagrams 📦
  • Encapsulation can't be used unless it's known in advance that the node at the tunnel exit point can decapsulate the datagram 🫠

Since most Internet nodes today don't perform well when IP loose source route options are used, the second technical disadvantage of encapsulation isn't as serious as it first seems 🌸 Plot twist, the vibes check out ✨

3. IP in IP Encapsulation 🦋

To encapsulate an IP datagram with IP in IP encapsulation, an outer IP header [10] gets inserted before the datagram's existing IP header. It goes like this 👇

                                         +---------------------------+
                                         |                           |
                                         |      Outer IP Header      |
                                         |                           |
     +---------------------------+       +---------------------------+
     |                           |       |                           |
     |         IP Header         |       |         IP Header         |
     |                           |       |                           |
     +---------------------------+ ====> +---------------------------+
     |                           |       |                           |
     |                           |       |                           |
     |         IP Payload        |       |         IP Payload        |
     |                           |       |                           |
     |                           |       |                           |
     +---------------------------+       +---------------------------+

The outer IP header's Source Address and Destination Address identify the "endpoints" of the tunnel 🧚 The inner IP header's Source Address and Destination Address identify the original sender and recipient of the datagram, respectively ✨ The encapsulator doesn't change the inner IP header, except to decrement the TTL as described below. It stays unchanged while the datagram travels to the tunnel exit point 🫶 No changes happen to IP options in the inner header during delivery through the tunnel. If needed, other protocol headers, like the IP Authentication header [1], may be inserted between the outer IP header and the inner IP header 🔐 Also, the security options of the inner IP header MAY affect the choice of security options for the encapsulating (outer) IP header 👑

3.1. IP Header Fields and Handling 💅

The encapsulator sets the fields in the outer IP header like this 🎀

  • Version
    • 4
  • IHL
    • The Internet Header Length (IHL) is the length of the outer IP header, measured in 32-bit words [10] 📏
  • TOS
    • The Type of Service (TOS) gets copied from the inner IP header 📋
  • Total Length
    • The Total Length measures the length of the entire encapsulated IP datagram. That includes the outer IP header, the inner IP header, and the payload 📦
  • Identification, Flags, Fragment Offset
    • These three fields are set as specified in [10]. Now, if the "Don't Fragment" bit is set in the inner IP header, it MUST be set in the outer IP header 🚫 If the "Don't Fragment" bit is not set in the inner IP header, it MAY be set in the outer IP header, as described in Section 5.1 ✨
  • Time to Live
    • The Time To Live (TTL) field in the outer IP header gets set to a value that's right for delivering the encapsulated datagram to the tunnel exit point ⏳
  • Protocol
    • 4
  • Header Checksum
    • The Internet Header checksum [10] of the outer IP header 🧮
  • Source Address
    • The IP address of the encapsulator, which is the tunnel entry point 🚪
  • Destination Address
    • The IP address of the decapsulator, which is the tunnel exit point 🚪
  • Options
    • Options present in the inner IP header are generally NOT copied to the outer IP header 🙅‍♀️ However, new options specific to the tunnel path MAY be added. In particular, any supported types of security options of the inner IP header MAY affect the choice of security options for the outer header. It's not expected that there will be a one-to-one mapping of those options to the options or security headers picked for the tunnel 🧩

When you encapsulate a datagram, the TTL in the inner IP header gets decremented by one if the tunneling is happening as part of forwarding the datagram. Otherwise, the inner header TTL stays the same during encapsulation 🔄 If the resulting TTL in the inner IP header is 0, the datagram gets discarded and an ICMP Time Exceeded message SHOULD be returned to the sender 💀 And an encapsulator MUST NOT encapsulate a datagram with TTL = 0. Absolutely not 🙅‍♀️

The TTL in the inner IP header doesn't change when decapsulating. If the inner datagram has TTL = 0 after decapsulation, the decapsulator MUST discard the datagram 🗑️ If the decapsulator forwards the datagram to one of its network interfaces after decapsulation, it decrements the TTL as a result of doing normal IP forwarding ✨ See also Section 4.4 📎

The encapsulator can use any existing IP mechanisms that fit for delivering the encapsulated payload to the tunnel exit point 🧰 In particular, IP options are allowed, and fragmentation is allowed unless the "Don't Fragment" bit is set in the inner IP header 🧩 That fragmentation restriction is required so that nodes using Path MTU Discovery [7] can get the information they're looking for 🔍

3.2. Routing Failures 💀

Routing loops inside a tunnel are especially dangerous when they make datagrams arrive back at the encapsulator 😱 Imagine a datagram arrives at a router for forwarding, and the router figures out that it has to be encapsulated before going any further. Then:

  • If the IP Source Address of the datagram matches the router's own IP address on any of its network interfaces, the router MUST NOT tunnel the datagram. Instead, the datagram SHOULD be discarded 🚫
  • If the IP Source Address of the datagram matches the IP address of the tunnel destination (the tunnel exit point is typically chosen by the router based on the Destination Address in the datagram's IP header), the router MUST NOT tunnel the datagram. Instead, the datagram SHOULD be discarded 🚫

See also Section 4.4 📎

4. ICMP Messages from within the Tunnel ✨

okay so, after the encapsulator sends off an encapsulated datagram 📦, it might get an ICMP [9] message back from some router in the tunnel 🚇. Any router except the tunnel exit point, btw. What the encapsulator does next depends on which ICMP message it got. If the incoming message has enough info in it, the encapsulator MAY use it to make a similar ICMP message and send that to the originator of the original, unencapsulated IP datagram (aka the original sender) 💌. This is called "relaying" the ICMP message from the tunnel, and it's giving very helpful middleman energy 🫶.

ICMP error messages include a copy of (a portion of) the datagram that caused the error. To relay one, the encapsulator has to strip off the outer IP header from that returned copy of the original datagram 🪡. If the ICMP message doesn't have enough data to relay, check out Section 5 🔍.

4.1. Destination Unreachable (Type 3) 🚫

Destination Unreachable messages get handled by the encapsulator based on their Code field 🧩. The model here lets the tunnel "extend" a network so it can include non-local (e.g., mobile) nodes 📱. So if the original destination in the unencapsulated datagram is on the same network as the encapsulator, some Destination Unreachable Code values may be changed to fit this model 🌸.

Network Unreachable (Code 0)

An ICMP Destination Unreachable message SHOULD be sent back to the original sender 💌. If the original destination in the unencapsulated datagram is on the same network as the encapsulator, the new Destination Unreachable message the encapsulator makes MAY have Code 1 (Host Unreachable). Why? Because the datagram presumably reached the correct network, and the encapsulator is basically trying to make it look like the original destination is local to that network, even if it isn't 🎭. Otherwise, if the encapsulator returns a Destination Unreachable message, the Code field MUST be set to 0 (Network Unreachable) 💅.

Host Unreachable (Code 1)

The encapsulator SHOULD relay Host Unreachable messages to the sender of the original unencapsulated datagram, if possible 🎀.

Protocol Unreachable (Code 2)

When the encapsulator gets an ICMP Protocol Unreachable message, it SHOULD send a Destination Unreachable message with Code 0 or 1 (see the discussion for Code 0) to the sender of the original unencapsulated datagram 🦋. Since the original sender didn't use protocol 4 when sending the datagram, sending Code 2 back to them would be meaningless 🙈.

Port Unreachable (Code 3)

This Code should never be received by the encapsulator, since the outer IP header doesn't refer to any port number 🧚. It MUST NOT be relayed to the sender of the original unencapsulated datagram 🚫.

Datagram Too Big (Code 4)

The encapsulator MUST relay ICMP Datagram Too Big messages to the sender of the original unencapsulated datagram 📏✨.

Source Route Failed (Code 5)

This Code SHOULD be handled by the encapsulator itself 🛠️. It MUST NOT be relayed to the sender of the original unencapsulated datagram 🙅‍♀️.

4.2. Source Quench (Type 4) 🌊

The encapsulator SHOULD NOT relay ICMP Source Quench messages to the sender of the original unencapsulated datagram 🙅‍♀️. Instead, it SHOULD turn on whatever congestion control mechanisms it has to help ease the congestion detected inside the tunnel 🌈.

4.3. Redirect (Type 5) 🧭

The encapsulator MAY handle ICMP Redirect messages itself 💜. It MUST NOT not relay the Redirect to the sender of the original unencapsulated datagram 🙈.

4.4. Time Exceeded (Type 11) ⏳

ICMP Time Exceeded messages point to (presumed) routing loops inside the tunnel itself 🔁. When the encapsulator receives a Time Exceeded message, it MUST report it to the sender of the original unencapsulated datagram as Host Unreachable (Type 3, Code 1) 💌. Host Unreachable is preferred over Network Unreachable, and here's the logic: the encapsulator handled the datagram, and the encapsulator is often treated as being on the same network as the destination address in the original unencapsulated datagram. So the datagram is considered to have reached the correct network, just not the correct destination node inside it 🏠💖.

4.5. Parameter Problem (Type 12) 🧩

If a Parameter Problem message points to a field copied from the original unencapsulated datagram, the encapsulator MAY relay the ICMP message to the sender of the original unencapsulated datagram 🎁. Otherwise, if the problem is with an IP option the encapsulator inserted, the encapsulator MUST NOT relay the ICMP message to the original sender 🛑. Also, an encapsulator that follows prevalent current practice will never insert any IP options into the encapsulated datagram, except possibly for security reasons 🔐.

4.6. Other ICMP Messages 📬

Other ICMP messages aren't related to the encapsulation operations in this protocol specification, so the encapsulator should act on them as specified in [9] 🧃.

5. Tunnel Management 🏗️

Unfortunately, ICMP only requires IP routers to return 8 octets (64 bits) of the datagram beyond the IP header 😩. That's not enough to include a copy of the encapsulated (inner) IP header, so the encapsulator can't always relay an ICMP message from inside a tunnel back to the original sender 💔. BUT, by carefully keeping "soft state" about the tunnels it sends into, the encapsulator can return accurate ICMP messages to the original sender in most cases 🧠✨. The encapsulator SHOULD keep at least the following soft state information about each tunnel:

  • MTU of the tunnel (Section 5.1)
  • TTL (path length) of the tunnel
  • Reachability of the end of the tunnel

The encapsulator uses the ICMP messages it receives from inside a tunnel to update that tunnel's soft state 🔄. ICMP errors that could come from one of the routers along the tunnel interior include:

  • Datagram Too Big
  • Time Exceeded
  • Destination Unreachable
  • Source Quench

When later datagrams come in that would transit the tunnel, the encapsulator checks the tunnel's soft state 🔍. If a datagram would violate the tunnel's state (for example, the new datagram's TTL is less than the tunnel "soft state" TTL), the encapsulator sends an ICMP error message back to the sender of the original datagram 🚨. But it ALSO encapsulates the datagram and forwards it into the tunnel 💁‍♀️. Iconic multitasking 👑.

With this technique, the ICMP error messages the encapsulator sends won't always match up one-to-one with the errors that happened inside the tunnel 🙃. But they WILL accurately reflect the state of the network 🌐💜.

Tunnel soft state was originally developed for the IP Address Encapsulation (IPAE) specification [4] 🦋.

5.1. Tunnel MTU Discovery 📐

When the originator sets the Don't Fragment bit and it gets copied into the outer IP header, the tunnel's proper MTU will be learned from ICMP Datagram Too Big (Type 3, Code 4) messages reported to the encapsulator 📏. To support sending nodes that use Path MTU Discovery, all encapsulator implementations MUST support Path MTU Discovery [5, 7] soft state within their tunnels 🙌. There are several advantages here:

  • As a benefit of Path MTU Discovery inside the tunnel, any fragmentation caused by the size of the encapsulation header happens only once, after encapsulation 🧁. That stops a single datagram from being fragmented multiple times, which improves processing efficiency for the decapsulator and the routers in the tunnel ⚡.
  • If the source of the unencapsulated datagram is doing Path MTU Discovery, it's really useful for the encapsulator to know the tunnel's MTU 🎯. Any ICMP Datagram Too Big messages from inside the tunnel come back to the encapsulator, and as noted in Section 5, the encapsulator can't always relay ICMP messages to the source of the original unencapsulated datagram 😬. But by keeping "soft state" about the tunnel's MTU, the encapsulator can send correct ICMP Datagram Too Big messages back to the original sender, so that sender can do its own Path MTU Discovery 🫧. In this case, the MTU the encapsulator tells the original sender SHOULD be the tunnel's MTU minus the size of the encapsulating IP header 🎀. That way the encapsulator doesn't have to fragment the original IP datagram 💖.
  • If the source of the original unencapsulated datagram is NOT doing Path MTU Discovery, it's still super useful for the encapsulator to know the tunnel's MTU 🕵️‍♀️. Honestly it's way better to fragment the original datagram during encapsulation than to let the encapsulated datagram get fragmented 🙌. The encapsulator can fragment the original datagram without special buffer requirements and without the decapsulator having to keep reassembly state 🧠. By contrast, if the encapsulated datagram gets fragmented, the decapsulator has to reassemble it before decapsulating, which means it needs reassembly state and buffer space 😵‍💫.

So the encapsulator SHOULD normally do Path MTU Discovery, which means it has to send all datagrams into the tunnel with the "Don't Fragment" bit set in the outer IP header 🚀. BUT there are problems with this approach 🙃. When the original sender sets the "Don't Fragment" bit, the sender can react quickly to any returned ICMP Datagram Too Big error by retransmitting the original datagram 🏃‍♀️. On the other hand, suppose the encapsulator gets an ICMP Datagram Too Big message from inside the tunnel. If the original sender of the unencapsulated datagram did NOT set the "Don't Fragment" bit, there's nothing sensible the encapsulator can do to let the original sender know about the error 😭. The encapsulator MAY keep a copy of the sent datagram whenever it tries increasing the tunnel MTU, so it can fragment and resend the datagram if it gets a Datagram Too Big response 📦🔁. Or, the encapsulator MAY be configured so that, for certain types of datagrams, it doesn't set the "Don't Fragment" bit when the original sender of the unencapsulated datagram hasn't set it either ⚙️.

5.2. Congestion 🚦

An encapsulator might get signs of congestion from the tunnel, for example by receiving ICMP Source Quench messages from nodes inside the tunnel 🌊. Some link layers and various protocols that aren't part of the Internet suite might also give these signals in the form of a Congestion Experienced [6] flag 🚩. The encapsulator SHOULD reflect congestion conditions in its "soft state" for the tunnel 🪞. And when it forwards datagrams into the tunnel afterward, the encapsulator SHOULD use appropriate means for controlling congestion [3]; 🎛️ However, the encapsulator SHOULD NOT send ICMP Source Quench messages to the original sender of the unencapsulated datagram 🙅‍♀️💖.

6. Security Considerations ✨

okay bestie, this part is SERIOUS 😭 IP encapsulation can quietly lower the security of the whole Internet 💀 Anyone implementing or deploying it has to be careful. The big problem is that encapsulation makes it really hard for border routers to filter datagrams by their header fields. The original Source Address, Destination Address, and Protocol values in the IP header, plus the port numbers in any transport header inside the datagram, are no longer where they normally live once the packet is encapsulated 🙈 And since any IP datagram can be encapsulated and sent through a tunnel, filtering border routers have to examine every single datagram super carefully 🔍

6.1. Router Considerations

Routers need to know about IP encapsulation protocols so they can filter incoming datagrams correctly 🛡️ It's desirable for that filtering to be integrated with IP authentication [1] 🎀 When IP authentication is used, encapsulated packets might be allowed into an organization if either the encapsulating (outer) packet or the encapsulated (inner) packet is sent by an authenticated, trusted source 🫶 Encapsulated packets with no authentication at all are a potentially huge security risk 🚨

IP datagrams that are encapsulated AND encrypted [2] can also be a problem for filtering routers 🔐 Here, the router can only filter the datagram if it shares the security association used for the encryption 🧩 So if you want this kind of encryption in environments where every packet needs to be filtered (or at least accounted for), there must be a mechanism in place for the receiving node to securely pass the security association along to the border router 🌸 This might, more rarely, also apply to the security association used for outgoing datagrams 💜

6.2. Host Considerations

Hosts that can receive encapsulated IP datagrams SHOULD only admit datagrams that fit into one or more of these categories:

  • The protocol is harmless: source address-based authentication is not needed.
  • The encapsulating (outer) datagram comes from an authentically identified, trusted source. The authenticity of the source could be established by relying on physical security in addition to border router configuration, but it's more likely to come from use of the IP Authentication header [1] 🔑
  • The encapsulated (inner) datagram includes an IP Authentication header.
  • The encapsulated (inner) datagram is addressed to a network interface belonging to the decapsulator, or to a node the decapsulator has a special relationship with for delivering such encapsulated datagrams 🦋

Some or all of this checking could be done in border routers instead of the receiving node, but it's better if border router checks are used as a backup rather than being the only check 💅

7. Acknowledgements 🌈

Parts of Sections 3 and 5 of this document were taken from portions (authored by Bill Simpson) of earlier versions of the Mobile IP Internet Draft [8] 🙌 The original text for section 6 (Security Considerations) was contributed by Bob Smart 💖 Good ideas also came from RFC 1853 [11], which was also authored by Bill Simpson ✨ Thanks to Anders Klemets for finding mistakes and suggesting improvements to the draft 🍓 And finally, thanks to David Johnson for going over the draft with a fine-toothed comb, finding mistakes, improving consistency, and making lots of other improvements 👑

References

  • [1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
  • [2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
  • [3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  • [4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP Interoperability and Transition Mechanism", Work in Progress.
  • [5] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
  • [6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control Survey", RFC 1254, August 1991.
  • [7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
  • [8] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 1996.
  • [9] Postel, J., Editor, "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
  • [10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
  • [11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

Author's Address 📮

Questions about this memo can be directed to:

Charles Perkins
Room H3-D34
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY  10532

Work:   +1-914-784-7350
Fax:    +1-914-784-6205
EMail: perk@watson.ibm.com

The working group can be contacted via the current chair:

Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL  60196

Work:   +1-847-576-2753
EMail: solomon@comm.mot.com
📦 where this page comes from