Clik here to view.
The most common transition method for IPv6 (that is: how to enable IPv6 on a network that does not have a native IPv6 connection to the Internet) is a “6in4” tunnel. Even other tunneling methods such as Teredo or SixXS are found on different literatures. However, another method that is not often explained is to tunnel the IPv6 packets through a VPN connection. For example, if the main office has a native IPv6 connection to the Internet, as well as VPN connections to its remote offices, it is easy to bring IPv6 subnets to these stations.
Here is how I did it with some Juniper SSG firewalls:
I assume that there is already a VPN connection between two Juniper ScreenOS firewalls in place. If so, the steps to tunnel IPv6 through this VPN tunnel are quite easy. (Note that this is NOT a 6in4 tunnel! It is simply a forwarding of IPv6 packets through a common IPsec site-to-site tunnel.)
Tunneling
The following configuration steps are required:
- Enable IPv6 in the “host” mode on the tunnel interfaces
- Configure static IPv6 routes through these tunnel interfaces
- Do regular IPv6 stuff: Enable IPv6 with Router Advertisements at the remote site and configure the appropriate security policies
This is how my networks look like, followed by the configuration screenshots:
Image may be NSFW.
Clik here to view.
(For further information: Read the descriptions under the screenshots.)
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Done. Image may be NSFW.
Clik here to view.
Latency & Hop Count
One side note about the latency: Yes, since the IPv6 connection must travel through the IPv4 tunnel (with its hops to the main site) as well as through the native IPv6 Internet to the final destination, the total hop count (i.e., latency) is approximately doubled. However, I made an interesting observation: My main site has a quite good ISP connection with almost the same ping times of IPv4 and IPv6 (latency of 3-4 ms). My home site has a normal German DSL connection and I am surfing via WLAN –> IPv4 latency of about 23 ms. And now, my new IPv6 connection has an added latency of about 29 ms, which is compared to the native IPv4 connectivity not that bad. Image may be NSFW.
Clik here to view.
weberjoh@jw-nb09:~$ ping heise.de PING heise.de (193.99.144.80) 56(84) bytes of data. 64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=247 time=23.3 ms 64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=2 ttl=247 time=22.6 ms 64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3 ttl=247 time=23.1 ms 64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=4 ttl=247 time=23.8 ms ^C --- heise.de ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 22.644/23.251/23.888/0.486 ms weberjoh@jw-nb09:~$ weberjoh@jw-nb09:~$ weberjoh@jw-nb09:~$ ping6 heise.de PING heise.de(redirector.heise.de) 56 data bytes 64 bytes from redirector.heise.de: icmp_seq=1 ttl=54 time=29.4 ms 64 bytes from redirector.heise.de: icmp_seq=2 ttl=54 time=29.8 ms 64 bytes from redirector.heise.de: icmp_seq=3 ttl=54 time=30.4 ms 64 bytes from redirector.heise.de: icmp_seq=4 ttl=54 time=29.9 ms ^C --- heise.de ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 29.427/29.930/30.421/0.374 ms