SysAdminMag.com
An IPv6-to-IPv4 Web Proxy
Matt Ganis
As new technologies get introduced to the Internet, the rate of adoption seems to be tied to the ease at which they can be implemented. This seems to be the case with IP version 6, the next generation of the Internet Protocol. This article will attempt to help ease the transition to IPv6 by showing how to attach to the version 6 network and provide access to your company's existing Web site via a simple IPv6-to-IPv4 proxy. Using industry-standard tunneling, "free" IPv6 tunnel brokers, and the power of Linux, I will show how a company can easily have its Web site accessible on the traditional IPv4 network as well as the IPv6 network. The net result is a low-cost method for creating a presence on this new networking standard.
Background
Last summer, I was asked to enable our Web site for IPv6 access. I spent several days looking at solutions ranging from obtaining direct IPv6 routing so I could run a dual-stack machine supporting both traditional IPv4 and IPv6, to duplicating our Web site (hardware and software) and running two separate (yet identical) sites. Neither of these options was appealing from a cost perspective or a Web site maintenance perspective.
I chose a fairly simple solution, which was to build a proxy from the IPv6 network to the IPv4 site. Users connecting to the IPv6 site would have their pages served via a proxy to the original IPv4 site (see Figure 1). Although I would have to install one new piece of hardware for the proxy, I could serve two sites from one source (albeit from different locations). The problem then became where to find a cheap, reliable IPv6-to-IPv4 Web proxy, and the answer was simple -- use Linux!
IPv6 Connectivity
IPv6 is a new generation of the Internet Protocol that is beginning to be adopted by the Internet community. The most visible difference between today's commonly used version of IP (IPv4) and IPv6 is the larger address space supported by IPv6. The new protocol supports 128-bit Internet addresses, compared to the 32-bit Internet address supported by IP version 4. Thus, IPv6 is especially well suited for the next wave of Internet devices, such as mobile phones and appliances with potential addresses numbering in the trillions!
There are several ways to obtain connectivity to the IPv6 network. I chose a tunnel broker for my connectivity, but let's look at some other options as well. The most expensive solution is to route IPv6 traffic natively to the IPv6 Internet -- in other words, route the TCP/IP traffic just like you do today. This requires a new IPv6 router as well as additional connectivity with an ISP that actually routes native traffic. This is actually a good solution from the perspective that your IPv6 network and traffic can be kept separate from each other (important when you're just experimenting), but a poor solution from a cost perspective.
Most connectivity for IPv6 is done by IPv6-over-IPv4 tunneling. In this method, the existing IPv4 network is used to exchange IPv6 packets. To use IPv6-over-IPv4 tunneling, your site or hosting center will need to support an IPv4/IPv6 dual router that supports IPv6-over-IPv4 tunneling. The IPv6 packets from your network are encapsulated in IPv4 packets at your outbound router; the tunnel is terminated at your ISP where the packets are sent to the IPv6 Internet. This requires that your router support 6-to-4 translation. Vendors like Cisco already have this support, but, since this was an experimental activity, production hosting teams are cautious about configuring this kind of support into routers.
The 6-to-4 approach was designed to allow isolated IPv6 sites (more than one host) to easily connect to each other without having to wait for native IPv6 support from their ISP. The tunnel broker is designed for small, isolated IPv6 sites or hosts that are on the IPv4 network yet require access to the IPv6 network. There are several "for free" IPv6 tunnel brokers in the Internet including Hurricane Electric, SixXS, and BTExact. By far the easiest and most reliable tunnel broker I found was BTExact at:
https://tb.ipv6.btexact.com/Note, I am not affiliated with BTExact; I just liked their service. Tunneling Tunneling one protocol inside another is not a new phenomenon on the Internet. In this case, we simply define the IPv4 tunnel endpoints (my server is one end and the tunnel broker is the other), and all IPv6 traffic that is sent to or from my machine travels the regular Internet with the IPv6 packets stuffed inside of an IPv4 packet (see Figure 2). Once registered with your tunnel broker of choice, it's time to set up your tunnel. In the case of BTexact, they will conveniently send you a script to run to configure your tunnel endpoint. Currently, they support script generation for Linux, Solaris, Cisco, FreeBSD, and Windows. To check whether your server is enabled for IPv6, you can either:
cat /proc/net/if_inet6or issue:
/sbin/ifconfig -aand you should have devices sit0 and sit1 defined. SIT stands for Simple Internet Transition and will define the IPv6 tunnel for your server. If you don't see any sitx devices defined, try running modprobe ipv6 to load the kernel support. Here's an example of the script I use to enable my tunnel (courtesy of BTexact), which I call from /etc/rc.d/rc3.d/S99local at startup:
#!/bin/sh
if ! [ -f /proc/net/if_inet6 ]
then echo "IPv6 is not installed!" 1>&2; exit 1; fi
ifconfig sit0 up \
&& ifconfig sit0 inet6 tunnel ::213.121.24.85 \
&& ifconfig sit1 inet6 add 2001:618:400::cc92:e045/128 \
&& route -A inet6 add ::/0 gw fe80::d579:1855 dev sit1 \
&& echo "IPv6 configuration completed" || \
{ echo "IPv6 configuration failed!" 1>&2; exit 1; }
The address 213.121.24.85 is the IP address of the tunnel server at BTexact, and
the IPv6 address of my server is 2001:618:400::cc92:e045. Note that for tunneling
you need to allow IP packets that specify a protocol number of 41 through your
firewall destined to the IP address of your tunnel endpoint. Remember this is
not a port; it's a protocol number (like 6 for TCP or 17 for UDP). Refer to /etc/protocols
for a complete list.
To test the newly defined tunnel, try to ping a remote host with the ping6
command:
[root@sixgun root]# ping6 -n www.kame.net PING www.kame.net(2001:200:0:8002:203:47ff:fea5:3085) 56 data bytes 64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp_seq=1 \ ttl=54 time=483 ms 64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp_seq=2 \ ttl=54 time=483 ms 64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp_seq=3 \ ttl=54 time=483 msNote that certain commands for IPv6 use have the 6 appended to them (i.e., ping6 or traceroute6); others like netstat require you to specify additional parameters. For example, to see your routing table, use:
netstat -rn -A inet6To check your server from another node in the network, check out the site:
http://www.ipv6tools.com/where you can interactively ping or traceroute to your site. Setting up a DNS record on the site is straightforward (and doesn't necessarily require IPv6 on the server). I created a new test subdomain for this effort called ipv6-test.ibm.com and then defined a record for www like so:
www IN AAAA 2001:618:400::cc92:e045Configuring the Web Proxy Once the server is operational as an IPv6 node, it's time to configure the Web proxy. I used Apache2 for my proxy (for reasons I'll describe a bit later). Building Apache2 is relatively simple. To run a proxy, you must enable the mod_proxy module in your server. After untarring the source, I ran the configure command with the following parameters (in this case, I wanted all of the modules built into my httpd so I could easily configure new features). I'm not sure why I had to specify --enable-proxy to build mod_proxy when I specified --enable-modules=all, but it didn't work unless I did:
./configure --enable-proxy --enable-modules=allIn your httpd.conf, you need to add or modify the following directives:
# Listen on Port 80 for IPv6 Listen [::]:80 ExtFilterDefine fixtext-ipv6 mode=output intype=text/html \ cmd="/bin/sed s/www.ibm.com/www.ipv6-test.ibm.com/g" SetOutputFilter fixtext-ipv6 # # ProxyPass / http://www.ibm.com/ ProxyPassReverse / http://www.ibm.com/The Listen, ProxyPass, and ProxyPassReverse are also relatively straightforward. The ProxyPass directive allows a remote server to be mapped into the space of the local server; the local server does not act as a proxy in the conventional sense, but appears to be a mirror of the remote server (in this case, it appears to be a mirror of http://www.ibm.com). The ProxyPassReverse directive lets Apache adjust the URL in the Location header on HTTP redirect responses. This is essential when Apache is used as a reverse proxy to avoid bypassing the reverse proxy due to HTTP redirects on the backend servers. The ExtFilterDefine and setOutputFilter are interesting (and important) for the operation of this proxy. The SetOutputFilter directive sets the filters (defined by ExtFilterDefine) that will process responses from the server before they are returned to the client. The ExtFilterDefine directive defines the characteristics of an external filter, including the program to run and its arguments. In this case, I apply the simple sed command (to change all occurrences of www.ibm.com to www.ipv6-test.ibm.com) for any page accessed by the proxy before it's returned to the client. By doing this, I change all links on the page to point not to the original IPv4 site but to the IPv6 proxy instead (see Figure 3). To test your Web site proxy, you need a browser that is IPv6 capable. To be honest, I've lost track of which browsers do and don't support IPv6, but I use Opera on Linux, which works quite well. If you don't have a DNS entry setup, you can specify the IP address. Note, however, that it's not like IPv4; you have to include the host address in square brackets, like so:
http://[ 2001:618:400::cc92:e045]Conclusion
This proxy has proved to be quite simple to set up and has provided us with an almost instant presence on the IPv6 networks. I'm not claiming that I would use this for heavy amounts of traffic, but for an experimental setup, it can't be beat.
Matt Ganis is a Senior Technical Staff Member at IBM where he is also part of the ibm.com webmaster team. In his spare time, he teaches astronomy and computer science at Pace University in Westchester, New York. He can be reached at: [email protected].
