How to build an IPv6 tunnel over IPv4 GRE and IPSec

or

Set up your own 6in4 tunnel broker with Free Software

Abstract

This article shows how to configure an IPv4 GRE tunnel over IPSec, through which IPv6 packets can be forwarded. It describes how to configure the client and how to set up the tunnel broker, using a sample network layout. The purpose is to enable IPv6-capable hosts ("clients"), that are isolated in an IPv4-only network, to connect to the IPv6 internet.

Update: In the meantime, I have found a way to forward the IPv6 traffic natively over IPSec. See the updated article here. Thanks to Ryan Slack for pointing this out.

Table of contents

1. Introduction
   
2. Problem description
   
3. Solution approach
   
4. Systems used
   
5. Prerequisites
       For the client
       For the tunnel endpoint
   
6. Sample network layout
   
7. Setup
       The tunnel broker
       The client
   
8. Start
       The IPSec tunnel
       The GRE tunnel
       IPv6 forwarding
   
9. Final steps
   
10. Links
    

Introduction

With IPv6 slowly gaining more widespread application, many sites on the internet now offer their services over both IP protocols: IPv4 (the traditional way) and IPv6. This is possible because most (all?) internet carriers nowadays allow both protocols to be routed over their networks, so that, basically, the whole infrastructure of the internet is a multi-protocol transport layer, over which almost any protocol can be forwarded. Whereever segments exist over which a certain protocol cannot be transmitted, usually the edge routers of that segment make sure that the "offending" network packets are encapsulated within packets conforming with that particular segment's topology when entering the segment, and decapsulated again when leaving it.

I will not go into the specifics of packet encapsulation (also called "tunneling") here. It basically works by prepending a header and appending a trailer that contain routing/addressing information that is meaningful on the given segment, if the header/trailer of the original packet does not contain such information. The original packet usually is not modified, but merely embedded within the new packet. This additional information allows the new packet to traverse the network segment and is removed again once it reaches the segment's boundary (edge router). (See here for a brief introduction.)

You can think of it in an analogy: A Chinese businessman abroad in Europe wants to send a letter home to his family, who lives in rural China. Unfortunately, the post offices in Europe can only handle letters that have the addressee's name and address written in Latin characters, while the Chinese post office can only handle letters with addresses written in Chinese characters. So one solution would be to put the letter in an envelope that carries the address in Chinese characters, and then put that envelope into a second envelope that carries the address in Latin characters. On the second envelope he'd also write, in Chinese, "Remove this envelope when this letter enters China." So the European post office will understand the address on the outer envelope and put the letter on a plane to China, where the Chinese post office will remove the outer envelope and send the original letter onwards in the inner envelope. This is, more or less, how encapsulation works.

The problem:

Above I said that "the whole infrastructure of the internet is a multi-protocol transport layer". Well, unfortunately not all of it, not yet. While data centers and carrier networks are all well connected, most small office and home internet connections are still limited to the use of one protocol only: the traditional IPv4. Besides missing out on a technology that has been in active use on the internet for well over 10 years, this is increasingly causing problems for home customers. One reason is, paradoxically, that many home and office computers are absolutely capable of doing IPv6 (all modern operating systems support it natively). Now if a site is available over both IPv4 and IPv6, most computers will first try IPv6, and switch back to IPv4 only if that fails. In many systems that means waiting until the IPv6 attempt creates a timeout, which noticeably slows down every connection attempt. Some operating systems have implemented workarounds to deal with that situation, but that's all they are: workarounds... And that's just one of many possible problems.

Fig. 1: Schematic illustration of the problem: The client can't connect to any IPv6 Server on the internet, because IPv6 traffic (red) is not possible directly over the ISP's network and routers. Only IPv4 traffic (blue) is transported. Any IPv6 connection attempt will fail and may create noticeable delays before switching to IPv4, depending on the client's operating system.

The solution:

One possible solution is to use encapsulation (tunneling). This is what we'll be looking at in the rest of this article. Starting at the home computer (which must, of course, be cabable of doing IPv6), we'll encapsulate our IPv6 packets in IPv4 "envelopes" and send them to a router that is connected to a IPv6 capable network. As the "envelope protocol" we will use a simple, multi-purpose tunneling protocol called GRE (Generic Routing Encapsulation, developed by Cisco). The router will decapsulate the packets ("remove the envelope") and forward our original IPv6 packets to the internet (for better security we will also be using IPSec for encryption and authentication of the tunnel).

Fig. 2: Schematic illustration of the solution: The client establishes an IPSec tunnel with the tunnel endpoint over IPv4 (blue). Within that tunnel, a second tunnel is established using GRE. This GRE tunnel is used to encapsulate all IPv6 traffic (red) from the client. The tunnel endpoint terminates (removes) both tunnels and sends on the client's IPv6 traffic to any IPv6 Server on the internet. From the ISP's point of view, still only IPv4 traffic (blue) is transported. IPv4 Servers on the internet are still reached via the "old" route over the ISP directly.

There are various ways to do this. If you search for "6in4 tunnel" or "6to4 tunnel" on the internet, you will find quite a lot of possibilities. Most of them assume that you have control over the home computer, but not over the router on the other side of the tunnel, who does the actual forwarding. Those routers are usually operated by networking companies, with whom you need to set up an agreement beforehand and who will then give you the access and configuration details. As of this writing, most of these companies (so called "tunnel brokers") offer their services for free (albeit with no guarantee that this remains free in the future). Currently, Hurricane Electric and SixXS are the most popular services. Both use different technologies to achieve their goal.

Of course, if you don't have a remote machine that is connected to the IPv6 internet and that you can configure as your tunnel endpoint, a public tunnel broker is most likely the way you need to go. Even if it means routing large portions of your internet traffic via the data centers of an US company (in the case of Hurricane Electric), which, in the wake of the NSA/Snowden case, leaves a bit of a bad taste in the mouth.

Now, given that I like to have control over my internet traffic and that I do have control over machines that are connected to the IPv6 internet, I decided to give it a try myself. As an IT engineer with a strong Free Software background, it was natural to try this with software tools that are freely availably and open source. Here's what I've used for this setup:

Systems used:

Home computer:

• Gentoo Linux ~amd64
• Kernel 3.16.0
• StrongSwan
• OpenSSL
• iproute2

• OpenBSD 5.6-current amd64
• iked
• LibreSSL

Prerequisites

• For the home computer:
  
  • IPv6 and IPv4 dual-stack capability.
    Most modern Linux distributions should be fine. If compiling your own kernel, make sure at least the following options are set:

    CONFIG_NET=y
CONFIG_INET=y
CONFIG_IPV6=y


  • GRE tunneling capability.
    Under Linux, that capability is either compiled into the kernel or provided by the module "ip_gre". To check if your kernel already supports GRE tunnels, run the command:

    ip tunnel
    

    (If you don't have the ip command, you need to install the iproute2 package.) You should see output like the following:

    gre0: gre/ip remote any local any ttl inherit nopmtudisc
ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16
tunl0: ip/ip remote any local any ttl inherit nopmtudisc
    

    If you see the line starting with gre0:, you're fine. Else try to load the module first:

    modprobe ip_gre
    

    and run ip tunnel again. If you still don't get a gre0: line, you need to compile your own kernel. To compile GRE into the kernel, make sure at least the following options are set:

    CONFIG_NET_IPGRE_DEMUX=y
CONFIG_NET_IPGRE=y

  • IPSec and IKEv2 capability.
    On Gentoo, I installed and used the strongswan package. On the kernel side, you will need at least these options set:

    CONFIG_INET_ESP=y
CONFIG_INET_AH=y
CONFIG_INET_IPCOMP=y
CONFIG_NET_IPIP=y


  We need IKEv2 to be able to dynamically assign a "virtual" IP address to the client (home computer). In theory, it would be possible to do without the "virtual" IP addresses for the GRE tunnel endpoints, but that would require a more complex IPSec setup. Besides, there appear to be some incompatibilities between strongswan and OpenBSD's iked that prevent this.
  

  • A X.509 certificate (with corresponding private key and CA chain) for the home computer or connecting user. It must contain an e-mail address or a FQDN as Subject Alternative Name (both may, but should not be, fictious). In this article we assume that the client certificate has a Subject Alternative Name of email:client@my.domain.
  
  
  • An internet connection (IPv4) that can hide NAT (masquerade) and forward UDP packets statefully (most home/WLAN routers shipped by ISPs can).
  
  
• For the tunnel endpoint:
  
  • An IPv4/IPv6 dual-stack network segment (ie. a network than can transport both protocols), that has access to the IPv6 internet. In my case this is a subnet at my colocation provider. The IPv4 network need not be publicly reachable (in my case it is behind a NAT gateway firewall).
  
  
  • The possibility to install a dual-stack system (the tunnel endpoint) into that subnet (I used a kvm/qemu virtual machine on an existing host.)
  
  
  • At least two free (unused) IPv4 addresses that are from a dedicated network, which is not used at the tunnel site or in the home computer's network! They will serve as GRE tunnel endpoints.
  
  
  • At least two free (unused) IPv6 addresses that can be routed to the tunnel endpoint from the internet. (Those addresses could be from the same IPv6 subnet as the one that already exists in the dual-stack network segment, but this makes the routing setup a little more difficult. I've used a dedicated /120 IPv6 subnet from the /48 range assigned to me by my provider. That way I can later add different clients and assign a dedicated IPv6 address to each.) They will serve as client IPv6 address and client IPv6 default gateway, respectively.
  
  
  • Tunnel endpoint computer that is capable of GRE, IPSec and IKEv2
    Vanilla OpenBSD 4.8 or later fits the bill. I used 5.6-current, since much improvement has happened on the iked daemon since 4.8. (Note that -current releases in OpenBSD mean the current development branch. You might want to stick with the stable release instead, which is one minor number lower than -current, ie. 5.5 as of this writing.)
  
  
  • A X.509 certificate (with corresponding private key and CA chain) for the tunnel endpoint computer. It must contain the FQDN of the tunnel endpoint (ie. the hostname that the client connects to) as Subject Alternative Name. In this article we assume that the tunnel endpoint certificate has a Subject Alternative Name of DNS:tunnel.my.domain.
  
  
  • An internet connection (IPv4) that can NAT (static) and forward UDP packets statefully (most routers and firewalls can. In my case, the firewall at the colocation is also OpenBSD).
  
  

Network layout

The network addresses used in this article are only examples. You'll need to adjust them for your setup.

• Home network
  

  	IPv4	IPv6
  Network	192.168.0.0/24	N/A
  Home computer	192.168.0.2	N/A
  Default gateway (ISP/WLAN router)	192.168.0.1	N/A



• Colocation network (dual-stack)
  

  	IPv4	IPv6
  Network	192.168.100.0/24	2a00::0/120
  Tunnel endpoint computer	192.168.100.2	2a00::2
  Default gateway (firewall)	192.168.100.1	2a00::1



• Dedicated network for GRE tunnel endpoints
  

  	IPv4	IPv6
  Network	192.168.101.0/24	N/A
  Home computer	192.168.101.1	N/A
  Tunnel endpoint computer	192.168.101.2	N/A
  Default gateway	N/A	N/A



• Dedicated network for IPv6 client connectivity
  

  	IPv4	IPv6
  Network	N/A	2a00::100/120
  Home computer	N/A	2a00::101
  Tunnel endpoint computer	N/A	2a00::102
  Default gateway (for home computer)	N/A	2a00::102



• Public IPv4 addresses
  

  	IPv4	IPv6
  1) Hide NAT (home computer)	1.2.3.4	N/A
  2) Static NAT (tunnel endpoint)	5.6.7.8	N/A


¹⁾ This is the public IPv4 address of the home ISP/WLAN router, with which usually all computers in the home network are "visible" on the internet. It is assigned by the ISP.
²⁾ This is the public IPv4 address at which the tunnel endpoint can be reached. In my case, this IP is routed to an outer firewall, which then translates ("NATs") all packets coming to that address into the tunnel endpoint's "private" address (192.168.100.2) and vice-versa for outgoing/reply packets.
• DNS (optional)
  As I run my own DNS servers, I used my domains to set up the hostname-to-IP translations. In this article, we will use "my.domain" as external DNS domain and "my.dmz" as internal (colocation) domain.
  

  	IPv4	IPv6
  tunnel.my.domain	5.6.7.8	N/A
  tunnel.my.dmz	192.168.100.2	2a00::2
  client.my.domain	N/A	2a00::101
  client.my.dmz	192.168.101.1	2a00::101



• Certificates
  We will be using X.509 certificates for mutual authentication of client and gateway when setting up the IPSec tunnel. All certificates need to be complete with private/public key pair and CA chain. The following list shows the assumed file names and on which systems they need to be present. (The file names are used below in the the example commands and are merely an example.)
  

  Description	File name	Tunnel endpoint	Home computer
  Gateway private key	endpoint.key	yes	no
  Gateway public key	local.pub	yes	no
  Gateway X.509 certificate	endpoint.pem	yes	no
  Gateway X.509 CA chain	endpoint-cachain.pem	yes	yes
  Client private key	client.key	no	yes
  Client X.509 certificate	client.pem	no	yes
  Client X.509 CA chain	client-cachain.pem	yes	yes

The setup

Done with the preliminaries, we can now proceed to bring this all together and set up our tunnel.

Set up the tunnel endpoint (gateway)

I installed the gateway on a kvm/qemu virtual machine with a bridged interface that connects to the dual-stack colocation network.
I used OpenBSD 5.6-current amd64 and followed the default install procedure.
I deselected all X related packages as well as game and compiler packages (-x*, -game*, -comp*)

The networking setup I chose during install resulted in the following files:

/etc/hostname.vio0 3)

inet 192.168.100.2 255.255.255.0
inet6 2a00::2


/etc/mygate 4)

192.168.100.1
2a00::1


Note: I am only giving the configuration files here. Most of the configuration can also be done via commands (ifconfig, route, ikectl etc.), so you might want to check out the (very comprehensive) OpenBSD manual pages.
Throughout the following it is assumed that you are logged in as root.

Next, I configured the necessary networking options in /etc/sysctl.conf (uncommented or added the following lines):

/etc/sysctl.conf

net.inet.gre.allow=1 # enable GRE
net.inet.gre.wccp=1 # not sure if this is needed for non-Cisco devices
net.inet.ip.forwarding=1 # enable IPv4 forwarding
net.inet6.ip6.forwarding=1 # enable IPv6 forwarding
net.inet.ipcomp.enable=1 # enable IP compression


With this, we could configure the system as a GRE tunnel endpoint. But since we want GRE (which is not encrypted or authenticated) to run over IPSec, we need to set up IPSec first. We will be using X.509 certificates for mutual authentication (this is not strictly necessary, but since I also have my own X.509 PKI, I find this easier.)

cp endpoint.key /etc/iked/private/local.key
chmod 600 /etc/iked/private/local.key

openssl rsa -in /etc/iked/private/local.key -pubout -out /etc/iked/local.pub

cp endpoint.pem /etc/iked/certs/

cp endpoint-cachain.pem /etc/iked/ca/

cp client-cachain.pem /etc/iked/ca/ ⁵⁾

Then, we need to configure iked, OpenBSD's Internet Key Exchange daemon, which is capable of doing IKEv2 key negotiations and network setup (see iked(8) and iked.conf(5)).
We set up an IKEv2 key exchange here, that will result in the client (home computer) receiving a "virtual" IPv4 address to use within the IPSec tunnel.
Note: If you don't want to or can't use IKEv2, you'll need isakmpd (see isakmpd(8)), which does IKEv1. But then much of the rest of this article will not apply to you.

/etc/iked.conf

# set up tunnel endpoint for road warrior to connect
ikev2 clientvpn \ 6)
  quick passive ipcomp esp inet \
  from 0.0.0.0/0 to 192.168.101.0/24 \ 7)
  peer 0.0.0.0/0 local 192.168.100.2 \ 7)
  srcid tunnel.my.domain dstid client@my.domain \
  config address 192.168.101.1 \
  config address 192.168.101.0/26 \ 8)
  # config netmask 255.255.255.0 \ 8)
  config protected-network 192.168.101.0/24 \
  tag ipsec-$id


Now, since we told iked to negotiate tunnels from anywhere to 192.168.101.0/24, we need to give the tunnel endpoint (gateway) an IPv4 address in that network. This will be the endpoint address of the GRE tunnel, that we will establish through the IPSec tunnel.
We do this by adding an alias line to /etc/hostname.vio0, so that it now reads:

/etc/hostname.vio0

inet 192.168.100.2 255.255.255.0
inet alias 192.168.101.2 255.255.255.0
inet6 2a00::2


Next, we need to prepare the system for the GRE (encapsulated) tunnel, through which it will receive the IPv6 packets from the home computer to forward. Given the above network layout, we set 192.168.101.1 as the client's GRE tunnel endpoint, and 192.168.101.2 as the gateway's GRE tunnel endpoint. Additionally, we set 2a00::102 as the IPv6 address of the gateway's GRE tunnel interface, which the home computer can use as default gateway for all IPv6 traffic. We also tell the system to take both sides of the tunnel up, irrespective of the actual network state (link0, the local side, is always set to up).

/etc/hostname.gre0

inet6 2a00::102 120
tunnel 192.168.101.2 192.168.101.1
link1 up


Finally, we enable iked to be started on system startup, and we tell it to log much debug information to /var/log/daemon:

/etc/rc.conf.local

# override default settings from /etc/rc.conf
pf=NO # we assume that we already are behind a firewall, so not running a local one
iked_flags="-vvv -6" 9) # maybe remove "-vvv" once the setup is stable
sndiod_flags=NO # no sound needed
sendmail_flags=NO # don't want sendmail as daemon
inetd_flags=NO # don't want inetd


With this, the gateway setup is complete. You can now restart all affected services manually or (as I prefer) simply reboot.

Set up the client (home) computer

The client setup - as the gateway setup - is fairly straight-forward. First (and given that your kernel is prepared for IPSec and GRE as shown above) you need to install the strongswan package. On Gentoo, this is done by running

emerge strongswan


Next, we need to configure StrongSwan IPSec.

Copy the home computer's RSA private key to /etc/ipsec.d/private and set permissions:

cp client.key /etc/ipsec.d/private/
chmod 600 /etc/ipsec.d/private/client.key

cp client.pem /etc/ipsec.d/certs/

cp client-cachain.pem /etc/ipsec.d/cacerts/

cp endpoint-cachain.pem /etc/ipsec.d/cacerts/ ¹⁰⁾

The following configuration options go into /etc/ipsec.conf:

/etc/ipsec.conf

config setup
  strictcrlpolicy=no
  charondebug="ike 4, enc 4, knl 4, cfg 2" #useful debugs

conn %default
  ikelifetime=1440m
  keylife=60m
  rekeymargin=3m
  compress=no
  mobike=yes

conn mytunnel
  type=tunnel
  keyexchange=ikev2
  auto=add
  # client settings
  left=%defaultroute
  leftcert=client.pem
  leftid=user@my.domain
  leftauth=pubkey
  leftsourceip=%config
  # gateway settings
  right=5.6.7.8 11)
  rightid=tunnel.my.domain
  rightauth=pubkey
  rightsubnet=192.168.101.0/24


Bring up the IPSec tunnel

If everything is configured correctly, you should be able to bring up your IPSec connection with the following two commands:

ipsec start
ipsec up mytunnel


If all goes well, you should receive output along the lines of:

ipsec start
Starting strongSwan 5.2.0 IPsec [starter]...

ipsec up mytunnel
initiating IKE_SA mytunnel[1] to 5.6.7.8
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from 192.168.0.2[500] to 5.6.7.8[500] (1132 bytes)
received packet: from 5.6.7.8[500] to 192.168.0.2[500] (457 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
local host is behind NAT, sending keep alives
remote host is behind NAT
received cert request for "CN=my.domain CA"
sending cert request for "CN=my.domain CA"
authentication of 'client@my.domain' (myself) with RSA signature successful
sending end entity cert "CN=Client, E=client@my.domain"
establishing CHILD_SA mytunnel
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(EAP_ONLY) ]
sending packet: from 192.168.0.2[4500] to 5.6.7.8[4500] (2220 bytes)
received packet: from 5.6.7.8[4500] to 192.168.0.2[4500] (1996 bytes)
parsed IKE_AUTH response 1 [ IDr CERT AUTH CPRP(ADDR ADDR) SA TSi TSr ]
received end entity cert "CN=tunnel.my.domain"
using certificate "CN=tunnel.my.domain"
using trusted ca certificate "CN=my.domain CA"
checking certificate status of "CN=tunnel.my.domain"
certificate status is not available
reached self-signed root ca with a path length of 0
authentication of 'tunnel.my.domain' with RSA signature successful
IKE_SA mytunnel[1] established between 192.168.0.2[client@my.domain]...5.6.7.8[tunnel.my.domain]
scheduling reauthentication in 86173s
maximum IKE_SA lifetime 86353s
installing new virtual IP 192.168.101.1
installing new virtual IP 192.168.101.55
connection 'mytunnel' established successfully


You can also see the new "virtual" ip addresses in the output of

ip addr show


[...]
10: wlan0: mtu 1500 qdisc mq state UP group default qlen 1000
  link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
  inet 192.168.0.2/24 brd 192.168.0.255 scope global wlan0
    valid_lft forever preferred_lft forever
  inet 192.168.101.1/32 scope global wlan0
    valid_lft forever preferred_lft forever
  inet 192.168.101.55/32 scope global wlan0
    valid_lft forever preferred_lft forever
  inet6 fe80::aabb:ccdd:eeff/64 scope link
    valid_lft forever preferred_lft forever


On the tunnel endpoint (gateway) you should see the IPSec SA and flow as follows:

ipsecctl -s all


The output should be along the lines of:

FLOWS:
flow esp in from 192.168.101.0/24 to 0.0.0.0/0 peer 1.2.3.4 srcid FQDN/tunnel.my.domain dstid UFQDN/client@my.domain type use
flow esp out from 0.0.0.0/0 to 192.168.101.0/24 peer 1.2.3.4 srcid FQDN/tunnel.my.domain dstid UFQDN/client@my.domain type require

SAD:
esp tunnel from 1.2.3.4 to 192.168.100.2 spi 0xabcdef01 auth hmac-sha1 enc aes
esp tunnel from 192.168.100.2 to 1.2.3.4 spi 0x12345678 auth hmac-sha1 enc aes


If any part of the setup so far fails, check /var/log/messages on the home computer and /var/log/daemon on the tunnel endpoint for errors and correct them.

Bring up the GRE tunnel and set up IPv6 through it on the home computer

Once the IPSec tunnel is up, we can continue to set up our GRE tunnel over it. On the home computer (client) run the following commands:

modprobe ip_gre


ip tunnel add gre6in4 mode gre ttl 255 remote 192.168.101.2 local 192.168.101.1 pmtudisc

ip link set gre6in4 up


ip -6 addr add 2a00::101 dev gre6in4


ip -6 route add ::/0 via 2a00::102 dev gre6in4 metric 1


19: gre6in4@NONE: mtu 1476 qdisc noqueue state UNKNOWN group default
  link/gre 192.168.101.1 peer 192.168.101.2
  inet6 2a00::101/120 scope global
    valid_lft forever preferred_lft forever
  inet6 fe80::ffee:ddcc:bbaa/64 scope link
    valid_lft forever preferred_lft forever


That's it!

If all went well, all that's left to do is to ensure that:

• Packets from the client 2a00::101 are allowed out to the internet via the colocation dual-stack network firewall (2a00::1). You might have to adjust your firewall rules for that.
  
  Since my firewall also runs on OpenBSD, this was a one-liner added to /etc/pf.conf
  

  # Allow ipv6-tunnel client out to internet
pass log quick inet6 from 2a00::101 to any


• Packets to 2a00::101 are routed to the tunnel endpoint on 2a00::2 (only the reply packets of established connections, of course!). This will most likely require an additional route for (at least) 2a00::101 via 2a00::2 on the firewall.
  
  On the OpenBSD firewall I just added the appropriate route command for the entire network 2a00::100/120 to the configuration file for the interface (em2 in my case) that connects to the dual-stack colocation network:
  

  /etc/hostname.em2

inet 192.168.100.1 255.255.255.0 192.168.100.255
inet6 2a00::1 120
!route add -inet6 2a00::100/120 2a00::2


ping6 2a00::102

PING 2a00::102(2a00::102) 56 data bytes
64 bytes from 2a00::102: icmp_seq=1 ttl=64 time=18.2 ms
64 bytes from 2a00::102: icmp_seq=2 ttl=64 time=17.7 ms
64 bytes from 2a00::102: icmp_seq=3 ttl=64 time=17.7 ms

ping6 www.google.com

PING www.google.com(zrh04s06-in-x10.1e100.net) 56 data bytes
64 bytes from zrh04s06-in-x10.1e100.net: icmp_seq=1 ttl=57 time=21.6 ms
64 bytes from zrh04s06-in-x10.1e100.net: icmp_seq=2 ttl=57 time=21.3 ms
64 bytes from zrh04s06-in-x10.1e100.net: icmp_seq=3 ttl=57 time=17.3 ms


Links

Well, I hope the above was helpful to you. Finding out how to set this up, working around bugs and incompatibilities, took some days. But thanks to other people who had posted their respective setups and experiences on the internet, I was finally able to pull it all together. Also, the members of the OpenBSD community (the misc@openbsd.org mailing list) were crucial in debugging some iked issues. Here are some of the helpful links I found:

• Setup of 6to4 tunnels (TLDP)
  
• OpenBSD: IPv6 Over IPv4 GRE Tunnel to Cisco Router (mindless.gr)
  
• tunneling (The Linux Foundation)
  
• Ipv6 Tunneling Over IPv4 Infrastructure (articlebase.com)
  

Feel free to send any suggestions, questions and corrections to the webmaster link below (requires javascript).