IP Encapsulation within IP
updated by
Extracted elements (24)
Encapsulation is preferred over IP loose source routing because source routing has unsolved security problems, causes performance problems in Internet routers, is often processed incorrectly, may be blocked by firewalls, and it is considered impolite for intermediate routers to modify datagrams they did not originate.
When a sender does not set the Don't Fragment bit, it is better for the encapsulator to fragment the original (inner) datagram before encapsulation than to allow the encapsulated datagram to be fragmented, because fragmenting the encapsulated datagram requires reassembly state and buffer space at the decapsulator.
ICMP only requires IP routers to return 8 octets (64 bits) of the datagram beyond the IP header when reporting errors, which is insufficient to include a copy of the encapsulated (inner) IP header; therefore it is not always possible for the encapsulator to relay ICMP messages from within the tunnel to the original sender.
All encapsulator implementations MUST support Path MTU Discovery soft state within their tunnels, so that fragmentation due to encapsulation overhead occurs only once and ICMP Datagram Too Big messages can be accurately relayed to original senders.
An encapsulator MUST NOT encapsulate a datagram with TTL = 0. When tunneling is done as part of forwarding, the inner IP header TTL is decremented by one before encapsulation; if the result is 0, the datagram is discarded and an ICMP Time Exceeded message SHOULD be sent to the sender.
ICMP Port Unreachable (Type 3, Code 3) messages MUST NOT be relayed to the sender of the original unencapsulated datagram, since the outer IP header does not refer to any port number.
ICMP Source Route Failed (Type 3, Code 5) MUST NOT be relayed to the sender of the original unencapsulated datagram; it should be handled by the encapsulator itself.
If, after decapsulation, the inner datagram has TTL = 0, the decapsulator MUST discard the datagram. The inner IP header TTL is not changed during decapsulation.
If the 'Don't Fragment' bit is set in the inner IP header, it MUST be set in the outer IP header as well, to support Path MTU Discovery by the original sender.
If the IP Source Address of a datagram to be tunneled matches the IP address of the tunnel destination (exit point), the router MUST NOT tunnel the datagram and SHOULD discard it, preventing routing loops.
Options present in the inner IP header are in general NOT copied to the outer IP header; however, new options specific to the tunnel path MAY be added, and inner header security options MAY affect the choice of security options for the outer header.
Reception of ICMP Time Exceeded (Type 11) messages MUST be reported to the sender of the original unencapsulated datagram as Host Unreachable (Type 3, Code 1), since the datagram reached the correct network but not the correct destination node.
The encapsulator MUST NOT relay ICMP Redirect (Type 5) messages to the sender of the original unencapsulated datagram; the encapsulator MAY handle them itself.
The encapsulator MUST relay ICMP Datagram Too Big (Type 3, Code 4) messages to the sender of the original unencapsulated datagram to support Path MTU Discovery.
The encapsulator SHOULD normally perform Path MTU Discovery by sending all datagrams into the tunnel with the 'Don't Fragment' bit set in the outer IP header; alternatively it MAY be configured not to set DF when the original sender did not set it.
The encapsulator SHOULD NOT relay ICMP Source Quench (Type 4) messages to the sender, but instead SHOULD activate its own congestion control mechanisms to alleviate congestion detected within the tunnel.
To prevent routing loops, if the IP Source Address of a datagram to be tunneled matches the router's own IP address on any interface, the router MUST NOT tunnel the datagram and SHOULD discard it instead.
When relaying an ICMP Datagram Too Big message to the original sender, the MTU value conveyed SHOULD be the tunnel MTU minus the size of the encapsulating IP header, to avoid fragmentation of the original datagram by the encapsulator.
IP-in-IP encapsulation inserts an outer IP header before the original (inner) IP header. The outer header's Source and Destination Addresses identify the tunnel entry and exit points; the inner header identifies the original sender and recipient and is not modified during tunnel transit except for TTL decrement.
The encapsulator SHOULD maintain 'soft state' about each tunnel it uses, including at minimum: the MTU of the tunnel, the TTL (path length) of the tunnel, and the reachability of the tunnel exit point. This state is updated from ICMP messages received from within the tunnel.
Host implementations capable of receiving encapsulated IP datagrams SHOULD admit only datagrams where: the protocol is harmless without source-address authentication; the outer datagram is from an authentically identified trusted source; the inner datagram includes an IP Authentication header; or the inner datagram is addressed to the decapsulator or a node in a special delivery relationship.
IP encapsulation makes it difficult for border routers to filter datagrams based on header fields, because the original Source Address, Destination Address, Protocol, and transport port numbers are not in their normal positions after encapsulation. Border routers need to carefully examine all datagrams and be aware of IP encapsulation protocols.
Router filtering for encapsulated datagrams should be integrated with IP authentication (RFC 1826). Encapsulated packets lacking authentication from a trusted source represent a potentially large security risk; encrypted encapsulated datagrams can only be filtered if the router shares the relevant security association.
The outer IP header Version field is set to 4; Protocol field is set to 4 (IP-in-IP); TOS is copied from the inner IP header; Total Length covers the entire encapsulated datagram including both headers; Source Address is the encapsulator's address; Destination Address is the decapsulator's address.