IPv6 Tunneling Over an IPv4 Network James M. Moscola, David Lim, Alan Tetley Department of Computer Science Washington University Campus Box 1045 One Brookings Drive Saint Louis, MO 63130 December 13, 2001 Abstract Due to the growth of the internet, the current address space provided provided by IPv4, with only 4; 294; 967; 296 addresses, has proven to be inadequate. Because of IPv4’s shortcomings, a new protocol, IPv6, has been created to take its place. This new protocol, using its 128-bit address scheme (thats 7x1023 addresses per square meter of earth!), should provide enough addresses for everyone’s computer, refrigerator and their toaster to have a connection to the internet. To help facilitate the movement from an IPv6 internet to an IPv4 internet we have created a module for the the Field Programmable Port Extender (FPX) in accordance with RFC1933. This module allows IPv6 packets coming from an IPv6 network to be packed into IPv4 packets, tunneled through an IPv4 network and then unpacked at the other end of the tunnel before reentering an IPv6 network. This approach to incorporating the new IPv6 specification allows a progressive changeover of networks from IPv4 to the newer IPv6. The current implementation runs at 80 MHz. 1 1 Introduction Due to the growth of the internet, the current address space provided by IPv4, with only 4; 294; 967; 296 addresses, has proven to be inadequate. A new protocol, IPv6 [1], has been developed and promises to facilitate the continual growth of the internet community. IPv6 is capable of offering 2128 internet addresses which amounts to approximately 340 trillion trillion trillion addresses (no that is not a typo, it is truly 340 trillion3). There are several ways to make the transition from the current IPv4 internet implementation to the newer IPv6 internet implementation. The first option, and also the least likely to happen, is to choose a day and have everyone with network hardware and software change their implementation. This approach is highly unlikely to happen, and some might say even impossible. Another approach is to have new hosts and routers support both IPv4 and IPv6. This is a much more reasonable approach but still has some problems. Consider the situation where an IPv6 host is sending data to another IPv6 host. The host cannot predetermine the route the data takes along the way and therefore cannot guarantee all networks the data passes through will support IPv6. A third approach is to allow both IPv4 and IPv6 networks to reside on the internet and tunnel IPv6 packets through IPv4 networks [2]. In other words, when an IPv6 packet is leaving an IPv6 domain and entering an IPv4 domain, the packet is encapsulated in an IPv4 packet and transmitted through the network. When the packet reaches the other end of the IPv4 network the IPv4 headers are removed from the IPv6 packet and the IPv6 packet can continue on to an IPv6 domain. A module for the Field Programmable Port Extender (FPX) [3][4] has been created that implements the third method described above. The module contains support for both ends of the tunneling protocol and can both pack and unpack IPv6 packets into and from IPv4 packets. Figure 1 shows the layout of the tunneling modules between IPv6 and IPv4 networks. IPv6 IPv6 Host Host IP Tunneling IP Tunneling Module Module (Packer) (Unpacker) IPv6 IPv4 IPv6 Network Network Network Figure 1: Layout of Tunneling modules between IPv6 and IPv4 networks 2 Field Programmable Port Extender (FPX) The FPX is a reprogrammable logic device that provides a hardware platform for the user to deploy packet processing network modules. It acts as an interface between the line cards and the WUGS (Washington University Gigabit Switch) [5], and can be inserted between these devices as shown in Figure 2. The FPX is composed of two FPGAs: the Network Interface Device (NID) and the Reprogrammable Application Device (RAD) [6]. 2.1 Network Interface Device (NID) The NID controls how packet flows are routed to and from modules. It also provides mechanisms to dy- namically load router hardware modules over the network. The combination of these features allows these modules to be dynamically loaded and unloaded without affecting the switching of other traffic flows or the 2 Line IPP OPP Card FPXField− OC3/ programmable OC12/ Port IPP OPP OC48 Extender Gigabit Switch Fabric Line IPP OPP Card FPXField− OC3/ programmable IPP OPP OC12/ Port OC48 Extender Figure 2: Configuration for the WUGS, FPX, and the Line Cards processing of packets by other modules in the system. As show in Figure 3, the NID has several components, all of which are implemented in FPGA hardware. It contains a four-port switch to transfer data between ports; Virtual Circuit lookup tables (VC) on each port in order to selectively route flows; a Control Cell Processor (CCP), which is used to process control cells that are transmitted and received over the network; logic to reprogram the FPGA hardware on the RAD; and synchronous and asynchronous interfaces to the four network ports that surround the NID. Data Data SDRAM SDRAM Data Module Module Data SRAM SRAM RAD VC VC Four Port RAD Program SRAM CCP Switch VC VC NID EC EC FPX Switch LineCard Figure 3: Major Components of the FPX 2.2 FPX Reprogramability The RAD can be programmed and reprogrammed to hold user-defined network modules, and is connected to two SRAM and two SDRAM components (Figure 3). In order to reprogram the RAD over the network, 3 the NID implements a reliable protocol that fills the contents of the on-board RAM with configuration data that are transmitted over the network. As each cell arrives, the NID uses the data and the sequence number in the cell to write data into the RAD Program SRAM. Once the last cell has been correctly received, the FPX holds an image of the reconfiguration bytestream that is needed to reprogram the RAD. At that time, another control cell can be sent to the NID to initiate the reprogramming of the RAD using the contents of the RAD Program SRAM. The FPX supports partial reprogramming of the RAD by allowing configuration streams to contain commands that only program a portion of the logic on the RAD. Rather than issue a command to reinitialize the device, the NID writes the frames of reconfiguration data to the RAD’s reprogramming port. This feature enables the other modules on the RAD to continue processing packets during the partial reconfiguration. Similar techniques have been implemented in other systems using software-based controllers [7] [8]. 3 Protocol Wrappers Protocol Wrappers [9] [10] are used in the regular expression module to streamline and simplify the net- working functions to process ATM cells and AAL5 frames directly in hardware. They use a layered design and consist of different processing circuits within each layer. The block diagram of the Protocol Wrappers is shown in Figure 4. At the lowest level, the Cell Processor processes raw ATM cells between network inter- faces. At the higher levels, the Frame Processor processes variable length AAL5 frames. Different layers of abstraction are important for structuring a network because doing so allows applications to be implemented at specific levels where important details may be exposed and irrelevant details may be hidden. In this manner, an application that interacts with AAL5 frames can effectively use the Protocol Wrappers. IP Tunneling Module Data read Data written from network to network Frame Processor Cell Processor Figure 4: Block Diagram of IP Tunneling module in the Protocol Wrappers. 4 Implementation Details Several processing components have been combined with the Frame Wrappers to implement an IPv6 over IPv4 tunneler for the FPX. An overview of the design is shown in Figure 5. The Frame Wrappers pro- cess incoming ATM cells to provide the interior components with full AAL5 ATM frames. These internal components then check the frame to see if they should process the packet or pass it on. The Control Cell 4 Processor (CCP) sits on the back end of the Frame Wrappers and receives AAL0 control cells which are used to configure tunnels. It passes the information from these cells to the Address Lookup where they are stored. When the IPv6 component gets an IPv6 packet, it checks the Address Lookup to see if it should be packed. This is determined by checking if the destination IP is part of a known subnet. If a match is found, the packet must be packed since its next hop is part of an IPv4 network. Otherwise the packet is routed like a normal IPv6 packet. The other end of the tunnel is handled by the IPv4 component. This component processes incoming IPv4 packets and checks the destination IP and the IP protocol field to determine if the packet should be unpacked, and does this process if necessary. If not, the packet is routed like a normal IPv4 packet. Even though both ends of the tunnel have been implemented, both ends do not have to be this implementation. Since RFC1933[2] has been followed, either end of the tunnel can be any other router or host that also follows this specification. Address Lookup Data read Data written from network Packer Unpacker to network Cell Processor IPv6 Processor IPv4 Processor Frame Processor Cell Processor Figure 5: Flow Diagram for IP Tunneling Module 4.1 IPv6 Processor The general design of the IPv6 component is seen in Figure 6. As frames enter the IPv6 component, they are first buffered into a FIFO (1). This is necessary since the Address Lookup component can take an indeterminate and variable amount of time to respond to lookup requests.