Jump to content

IP in IP

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 27.49.96.131 (talk) at 05:55, 25 May 2016 (→IP Packet encapsulated in IP Packet). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

IP in IP is an IP tunneling protocol that encapsulates one IP packet in another IP packet. To encapsulate an IP packet in another IP packet, an outer header is added with SourceIP, the entry point of the tunnel and the Destination point, the exit point of the tunnel. While doing this, the inner packet is unmodified (except the TTL field, which is decremented). The Don't Fragment and the Type Of Service fields should be copied to the outer packet. If the packet size is greater than the Path MTU, the packet is fragmented in the encapsulator, as the outer header should be included. The decapsulator will reassemble the packet.

IP Packet encapsulated in IPs Packet

Outer IP header Inner IP header IP Payload
IP in IP Encapsulation

Outer IP header have the following fields:

Version: 4 bits
This field is the Protocol version number. It is always 4 as IP in IP is supported for IPv4

Header Length: 4 bits
This field is the length of outer IP header

Type of Service (TOS): 8 bits
This field is copied from the inner IP header

Total Length: 16 bits
This field is the length of the encapsulated IP header (including Outer IP header, Inner IP header, IP Payload)

Identification: 16 bits
This field is used to identify the fragments of a datagram which will be helpful while reassembling the datagrams as encapsulator might fragment the datagram. For the outer IP header a new number is generated.

Flags: 3 bits

R DF MF

R: 1 bit
This bit is reserved and should be 0.
DF: 1 bit
This field specifies whether the datagram can be fragmented or not. If this bit is set to 1 in the inner header, then the outer header also have this bit set to 1 saying that this datagram cannot be fragmented. If this bit is set to 0 in the inner header, then the outer header may set to 0/1.
MF: 1 bit
This field is required when the datagram is fragmented saying whether the datagram contains some more fragments. This field is not copied from inner header.

Fragment Offset: 13 bits
This field is used while reassembling the fragments.

Time To Live (TTL): 8 bits
This field is used to track the lifetime of the datagram. The inner header TTL is decremented before encapsulation and is not changed in decapsulator. The outer header TTL is set to value such that the datagram is delivered to tunnel end point.

Protocol: 8 bits
This field indicates the next protocol following this datagram. The value is set to 4. Most cases the protocol will be IPv4 unless there is some additional headers for encapsulated packet.

Header Checksum: 16 bits
This field is the IP checksum of outer header.

Source IP Address: 32 bits
This field is the IP address of the encapsulator

Destination IP Address: 32 bits
This field is the IP address of the decapsulator

Options: Variable length
This field in general is NOT copied from the inner IP header. New options can be added.

Padding. Variable length.
This field is used to fill the datagram so that IP Payload starts on a 32 bit boundary.

Handling ICMP Messages

After sending a datagram, there may be chances of encapsulator getting ICMP messages from intermediate nodes. The encapsulator takes action for ICMP message depending on the Type and Code of the ICMP messages. The following are the ICMP messages with Type and Code as well as the action taken by the encapsulator:

  • Destination Unreachable (Type 3)
    • Network Unreachable (Code 0) – ICMP error message with Type 3 Code 0 should be sent to original sender.
    • Host Unreachable (Code 1) – ICMP error message with Type 3 Code 0 should be sent to original sender.
    • Protocol Unreachable (Code 2) – ICMP error message with Type 3 Code 0 or 1 should be sent to original sender.
    • Port Unreachable (Code 3) – No ICMP error message should be sent to original sender.
    • Datagram too big (Code 4) – ICMP error message with Type 3 Code 4 should be sent to original sender.
    • Source Route Failed (Code 5) – No ICMP error message should be sent to original sender.
  • Source Quench (Type 4) – No ICMP error message should be sent to original sender
  • Redirect (Type 5) – No ICMP error message should be sent to original sender
  • Time Exceeded (Type 6) – ICMP error message with Type 3 Code 1 should be sent to original sender (Case of Routing loops within tunnels)
  • Parameter Problem (Type 12)
    • If the error message points to a field copied from unencapsulated datagram, then the ICMP error message should be sent to original sender.
    • If the error message points to a field inserted by encapsulator, then the ICMP error message should not be sent to original sender

Handling Tunnel Loops

Loops may occur within a tunnel due to the following reasons:

  1. when the source IP of the datagram is same as the router's IP address in any of the interface.
  2. when the source IP of the datagram is same as the tunnel end point.

In both the cases, the router MUST NOT tunnel the datagram. Instead it should discard the datagram.

Tunnel Management

For ICMP messages intermediate routers return 64 bits of the datagram beyond the IP header which is not enough to copy Inner header. So the encapsulator will not be able to relay the appropriate message to the original sender. But this can be handled by maintaining the soft state of the tunnel. The soft state information maintained by the tunnel includes the following:

  • MTU of the tunnel
  • TTL of the tunnel
  • Reachability of the decapsulator

References

RFC 2003

Retrieved from "https://en.wikipedia.org/w/index.php?title=IP_in_IP&oldid=721976309"