Previous Page
Next Page

4.1. Introduction

In this chapter, we introduce the notion of tunnels and tunneling. Tunneling is a way of forming a virtual network on top of a physical network. That's a bit murky for a definition, but let's agree to accept it provisionally until we look at an example.

Suppose that we have two Novell Netware local area networks (LANs) in separate locations that we would like to connect through the Internet. Novell networks use IPX packets for their network-layer encapsulation and thus cannot route packets on an IP network directly.

IPX provides a connectionless unreliable datagram service similar to that provided by IP in TCP/IP.

There are several ways of linking the two LANs; one way, suggested in RFC 1234 [Provan 1991], is shown in Figure 4.1.

Figure 4.1. Tunneling IPX Packets Through the Internet


The IP gateway attached to Novell network 1 listens for IPX packets on the LAN, encapsulates them in UDP datagrams, and sends them over the Internet to the IP gateway attached to Novell network 2. When a UDP datagram arrives at the second gateway, the gateway removes the IPX packet from the UDP datagram and injects it into the second Novell LAN.

We say that we have tunneled IPX through the IP network. In terms of our provisional definition, we have overlaid a virtual IPX network onto an IP network. A slightly different viewpoint is that our tunnel simulates a direct wire between the two LANs. An essential aspect of both views is that the traffic in the tunnel does not interact with the rest of the IP network; a packet enters one end of the tunnel and can leave only through the other end. While in the tunnel, the IPX packet plays no role in its routing or delivery. To the Internet infrastructure, the IPX packets are merely opaque data.

Note that our tunnel provided no security: The data in the tunnel was neither encrypted nor authenticated. This lack of security would not be acceptable in most practical situations; enterprises want their data to be safe from prying eyes and protected from alteration. In this chapter, we focus on tunneling technology and defer discussion of the security aspects until we consider virtual private networks in Part 2.

As we mentioned in Chapter 2, the fundamental notion in tunneling is encapsulation, where each layer in a protocol stack encapsulates the data from higher layers by adding a header and perhaps a trailer to that data. Thus, we have a TCP segment encapsulated in an IP datagram, which is in turn encapsulated in an Ethernet frame.

In Chapter 2, all our examples of encapsulation involved a lower layer encapsulating the data of a higher layer. Our Novell example turns this on its head: The network-layer IPX packet is encapsulated in the transport-layer UDP datagram. A lower-layer protocol is encapsulated in a higher-layer protocol.

This leads us to a better definition for a tunnel: Tunneling is the act of encapsulating the data from one protocol in the data of a protocol at the same or higher layer. The encapsulating protocol is said to be a tunnel for the lower-layer protocol. Although the Novell example does not make it clear, the lower-layer protocol can encapsulate higher-layer protocols as usual. Figure 4.2 shows a typical example.

Figure 4.2. PPP Frames Tunneled in UDP


In this case, UDP is encapsulating a PPP frame that is carrying a TCP segment: We are tunneling PPP in UDP. Tunnels like this are easy to build, as we shall see later. For now, let's look at a tunnel like this in operation.

We build the tunnel between laptop and bsd, as shown in Figure 4.3.

Figure 4.3. A PPP in UDP Tunnel


The endpoints of the PPP connection are 192.168.0.1 at bsd and 192.168.0.2 at laptop. We label this a virtual PPP connection because the data actually flows through the tunnel on the 172.30.0.0/24 segment, as shown by the shaded path, rather than directly between the two PPP interfaces.

After bringing the tunnel up, we ping 192.168.0.1 from laptop and capture the traffic with tcpdump. Here is the output for a single ping:

1   12:22:09.215457 laptop.1050 > bsd.7050: udp 88
1.1    4500 0074 0565 0000 4011 1ccb ac1e 000c    E..t.e..@.......
1.2    ac1e 0001 041a 1b8a 0060 881b ff03 0021    .........'.....!
1.3    4500 0054 0564 0000 4001 f3f1 c0a8 0002    E..T.d..@.......
1.4    c0a8 0001 0800 9ddf 4501 0000 b194 473f    ........E.....G?
1.5    2e48 0300 0809 0a0b 0c0d 0e0f 1011 1213    .H..............
1.6    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223    .............!"#
1.7    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233    $%&'()*+,-./0123
1.8    3435 3637                                  4567

The encapsulating UDP datagram is shown in boldface in lines 1.1 and 1.2. Notice that the source address is the 172.30.0.12 (0xac1e000c) interface of laptop, and that the destination address is the 172.30.0.1 (0xac1e0001) interface of bsd.

On line 1.2, we see the PPP header:

1.2    ac1e 0001 041a 1b8a 0060 881b ff03 0021     .........'.....!

There is no flag byte, because the FreeBSD PPP operates in synchronous mode when using UDP to carry PPP frames. In synchronous mode, PPP expects the synchronous digital line to provide the flag. For the same reason, there is no PPP trailer: The synchronous line provides the CRC.

Finally, in lines 1.31.8, we see the original IP datagram that carries the ICMP echo request:

1.3     4500 0054 0564 0000 4001 f3f1 c0a8 0002     E..T.d..@.......
1.4     c0a8 0001 0800 9ddf 4501 0000 b194 473f     ........E.....G?
1.5     2e48 0300 0809 0a0b 0c0d 0e0f 1011 1213     .H..............
1.6     1415 1617 1819 1a1b 1c1d 1e1f 2021 2223     .............!"#
1.7     2425 2627 2829 2a2b 2c2d 2e2f 3031 3233     $%&'()*+,-./0123
1.8     3435 3637                                   4567

Notice that the source address is 192.168.0.2 (0xc0a80002), the laptop end of the PPP connection. Similarly, the destination address is 192.168.0.1 (0xc0a80001), the bsd end of the PPP connection.

The tunnel in Figure 4.2 might seem contrived, but it is, in fact, quite typical. We shall see several examples of tunnels like it shortly. For now, notice that it is different from the tunnel in Figure 4.1. The tunnel used to link the two Novell LANs tunneled a network-layer protocol in a transport-layer protocol. The tunnel of Figure 4.2 tunneled an interface-layer protocol in a transport-layer protocol. This variety is typical. We shall see examples of an interface protocol tunneled in another interface protocol, of an interface protocol tunneled in a network-layer protocol, and of an interface protocol tunneled in a transport-layer protocol. Similarly, we will see examples of network- and transport-layer protocols tunneled in the protocols of equal or higher layers.


Previous Page
Next Page