|
|
4.2. IP-in-IP TunnelsLet's begin our case study of tunnels with an almost trivial example. In this tunnel, IP datagrams are encapsulated in IP datagrams, as shown in Figure 4.4. Figure 4.4. IP-in-IP Encapsulation
The outer IP header will have a protocol field of 4 (Figure 2.12), indicating that its payload is another IP datagram. The inner IP header will have a protocol field indicating the protocol that it is carrying. We can see an example of this by using the FreeBSD generic tunnel (gif) interface to build an IP-in-IP tunnel from laptop to bsd. On laptop, we configure the tunnel by first creating the gif interface and then configuring it with logical and physical addresses for both ends: laptop# ifconfig gif0 create laptop# ifconfig gif0 192.168.0.2 192.168.0.1 logical addresses laptop# gifconfig gif0 172.30.0.12 172.30.0.1 physical addresses We verify the configuration of the tunnel by running ifconfig on laptop: laptop# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 172.30.0.12 --> 172.30.0.1
inet 192.168.0.2 --> 192.168.0.1 netmask 0xffffff00
inet6 fe80::a00:46ff:fe63:d630%gif0 prefixlen 64 scopeid 0x8The output shows that the logical address endpoints of the tunnel are 192.168.0.2 on the laptop side and 192.168.0.1 on the bsd side. The network, or physical, addresses of the endpoints are 172.30.0.12 and 172.30.0.1, the addresses of the physical interfaces on laptop and bsd. We do a corresponding configuration on bsd. When we capture a ping sent through this tunnel, we get 1 16:45:08.819974 laptop > bsd: 192.168.0.2 > 192.168.0.1: icmp: echo request (ipip-proto-4) 1.1 4500 0068 0f3d 0000 1e04 350c ac1e 000c E..h.=....5..... 1.2 ac1e 0001 4500 0054 0f3c 0000 4001 ea19 ....E..T.<..@... 1.3 c0a8 0002 c0a8 0001 0800 ec67 7101 0000 ...........gq... 1.4 54d2 473f 0782 0c00 0809 0a0b 0c0d 0e0f T.G?............ 1.5 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................ 1.6 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f .!"#$%&'()*+,-./ 1.7 3031 3233 3435 3637 01234567 The outer IP header is in boldface in lines 1.1 and 1.2. As we see from the tenth byte of the header, the protocol field is set to 4, IP-in-IP (Figure 2.12). The source address is 172.30.0.12 (0xac1e000c)the physical address of bsdas expected. Similarly, the destination address is the physical address of bsd, 172.30.0.1 (0xac1e0001). The inner IP header is on lines 1.2 and 1.3: 1.2 ac1e 0001 4500 0054 0f3c 0000 4001 ea19 ....E..T.<..@... 1.3 c0a8 0002 c0a8 0001 0800 ec67 7101 0000 ...........gq... This time, the protocol field is set to 1 (ICMP), and the source and destination addresses are 192.168.0.2 (0xc0a80002) and 192.168.0.1 (0xc0a80001). The utility of IP-in-IP tunnels may not be clear, so let's consider a common example. Suppose that we have two geographically separated networks with RFC 1918 (private) addresses and want to make the two networks appear as a single large network. For specificity, let's assume that the hosts in the first network have addresses in the 10.0.1.110.0.1.126 range and that the hosts in the second network have addresses in the 10.0.1.12910.0.1.254 range. When we say that the two networks should appear as a single large network, we mean that the host at 10.0.1.1 should be able to send a datagram directly to 10.0.1.129. That is, the IP datagram will have a source address of 10.0.1.1 and a destination address of 10.0.1.129. Note that we can't solve this problem with NAT, because the destination address is nonroutable. NAT can still adjust the source address, of course, but it can't compensate for the nonroutable destination address. We show a solution to this problem in Figure 4.5, where the two networks are connected by an IP-in-IP tunnel. The two gateway routers in the figure (GW1 and GW2) are called the tunnel endpoints. As shown in the figure, the physical addresses of the tunnel are 96.29.5.1 and 96.29.5.2. The logical endpoints are 10.0.1.126 and 10.0.1.254. Hosts on the left network have an entry in their routing table that specifies GW1 as the next hop for traffic addressed to the 10.0.1.128/25 network. Hosts on the right network have a similar entry in their routing table specifying GW2 as the next hop for the 10.0.1.0/25 network. Figure 4.5. An IP-in-IP Tunnel
When host H1 (10.0.1.1) wants to send a datagram to H129 (10.0.1.129), it first sends it to GW1because of the entry in the routing tablefrom which it is sent through the tunnel to GW2. When the encapsulated datagram reaches GW2, the outer IP header is stripped off, and the inner datagram is delivered to H129. Figure 4.6 shows this sequence of events for a ping packet sent from H1 to H129. Figure 4.6. Packet Flow from H1 to H129
The specification for IP-in-IP tunnels is in RFC 2003 [Perkins 1996]. This RFC is interesting because it points out some of the problems with tunneling that an implementer must deal with. For example, adding the extra IP header will enlarge the total packet by at least 20 bytes. This may cause the packet to exceed the MTU of the interface, so the tunnel endpoint must be prepared to deal with fragmentation. Now suppose that the original, inner, IP datagram had the don't-fragment (DF) bit set. RFC 2003 specifies that in that case, the tunnel endpoint must set the DF bit in the outer IP header also. Suppose that the size of the total datagram does not exceed the MTU of the tunnel endpoint but does exceed the MTU of a downstream router. Because the DF bit is set in the outer IP header, the router will send back an ICMP message indicating that fragmentation was required but that the DF bit was set. Recall from Chapter 2 that this ICMP message will contain the outer IP header and at least the first 8 bytes of the next header. In this case, those 8 bytes will be from the inner IP header, but as we see from Figure 2.11, that is not enough to determine the source address of the original IP datagram. Therefore, the tunnel endpoint will not be able, in general, to return the ICMP message to the originating host. To solve this problem, RFC 2003 recommends that the tunnel endpoint maintain soft state concerning the path MTU of the tunnel. When the endpoint receives an ICMP message indicating that fragmentation is required, it updates its notion of the path MTU for the tunnel. Then if a host sends a datagram for the tunnel that exceeds its path MTU, the endpoint can return an ICMP message directly to the host because it has the entire original IP header, including the source address. RFC 2003 recommends that tunnel endpoints maintain soft state on at least
This soft state allows the tunnel endpoint to return the appropriate ICMP error message to the originating host while it still has the host's source address. |
|
|
