 | ||
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.
Contents
IP Packet encapsulated in IPs Packet
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: 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:
Handling Tunnel Loops
Loops may occur within a tunnel due to the following reasons:
- when the source IP of the datagram is same as the router's IP address in any of the interface.
- 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: