Content uploaded by Karri Huhtanen
Author content
All content in this area was uploaded by Karri Huhtanen on May 12, 2021
Content may be subject to copyright.
Utilising IPv6 over VPN to Enhance Home Service Connectivity
Karri Huhtanen, Bilhanan Silverajan, Jarmo Harju
Tampere University of Technology, Institute of Communications Engineering, Korkeakoulunkatu 1, FIN-33720
Tampere, Finland
e-mail: firstname.surname@tut.fi
Keywords
IPv6 Connectivity, IPv6 over IPv4, IPv6 over VPN, Service Reachability, NAT
Abstract
The amount of home networks, as well as the number of services and hosts in them, is increasing. Often the home users
cannot get public IPv4 network allocations from service providers and are forced to use Network Address Translation
(NAT) and port forwarding to solve connectivity issues to the different home services. This paper introduces a secure
connectivity solution utilising both IPv6 and IPv6 transition mechanisms in cooperation with existing virtual private
network (VPN) solutions.
Introduction
The increased use of the NAT-enabled ADSL-routers, home gateways and WiFi access points has led to the situation
where same private addresses [1] are used in several different networks. At the same time, the need to reach home
services also from foreign networks has gradually increased as network attached storage, personal video recorders etc.
obtain IP connectivity. The solution for securing connectivity is usually Virtual Private Networking (VPN) software.
However, the collision of the same private network addresses in home and foreign networks causes a routing problem
(Figure 1), which can only be solved by adjusting the home network and VPN configuration each time the collision
occurs. This is not practical when considering usability of the home networks and because of this other solutions to the
problem must be considered.
Current IPv4 solutions and problems
One solution is to try to avoid the problem and try to select a private IPv4 network, which is unlikely to collide with
existing deployments. The network blocks like 10.0.0.0/8 and 172.16.0.0/12 can then be selected because of the large
address space of the first one and the somewhat rare use of the latter one. To make this selection transparent to home
user, the home gateways and ADSL routers should try automatically to randomize and even reduce the home network
address space by selecting networks, subnet masks and addresses, which are not likely to collide with each other. For
example, instead of configuring 192.168.0.0/24 network as a home network, a network like 172.30.42.64/27 (29
Figure 1: IPv4 routing conflicts
addresses for hosts) could be configured as the home network thus reducing the possibility of address and route
conflicts. Doing these kind of configurations manually however requires extensive understanding and knowledge of
computer networks. These are requirements, which most of home users cannot fulfil. Using IPv4 link local addresses
(169.254.0.0/16) [2] in home networks could be easier option to avoid collisions, but according to RFC 3927 these
addresses should not be distributed with the help of other software like DHCP or VPN server. A lot of WiFi hotspot
deployments also utilise IPv4 link local addresses, especially with those hosts unable to get address with DHCP, making
the utilisation of this address space nonfeasible.
Proposed Solution: Utilising IPv6 connectivity over VPN
Introduction
Our proposed solution (Figure 2) to avoid route conflicts and other problems with private IPv4 address space collisions
is to utilise 6to4 [3], an IPv6 transition mechanism, to obtain routable IPv6 network addresses first for home network
and services [4] and then, to utilise the same IPv6 network for connectivity by bridging it over VPN connection to the
mobile terminal. Because each IPv6 home network address space is now derived from unique, public IPv4 address,
there will not be any IPv6 route conflicts to disrupt access to the home network and its services. Additional advantage
of utilising the 6to4 IPv6 transition mechanism is that the IPv6 capable home services may now be accessed directly
from both 6to4 and native IPv6 Internet reducing the need to use VPN solution in situations where IPv6 connectivity
can be otherwise obtained. One of the additional advantages of utilising VPN connection, is also to obtain full IPv6
connectivity via home network even in the environments utilising double Network Address Translations (NAT) or
particularly strict firewalls creating an overlay network for enhanced terminal-to-terminal or terminal-to-services
connectivity.
Requirements
The main requirements of the proposed solution is that the home router has 6to4 functionality and all elements, i.e. the
router, home services and terminal are IPv6 capable. That requirement is already being filled partially, since all of the
major operating platforms like Microsoft Windows, Apple Mac OS X, Linux and Symbian already support IPv6 in their
operating systems and some vendors, like Microsoft, are even actively pursuing to enhance automatic IPv6
connectivity over IPv4 with the help of tunneling protocols like Teredo [5]. Most of the home routers however still lack
the possibility to use IPv6 at least with vendor supported firmware making the adoption of this technology harder for
the average user. For home router VPN there also exists a requirement either to support routing the IPv6 over IPv4 VPN
or to support bridging the home network segment over the IPv4 VPN. To reach the home router from foreign networks
Dynamic DNS (DDNS) must also be used to publish the home router's public IPv4 address in the Internet Domain
Name Service. For DNS based service discovery home service must also register its IPv6 address either to home
router's DNS service or to a public DDNS in the Internet.
Figure 2: Architecture of the proposed solution
Functionality
Figure 3 presents the functionality of the proposed solution. First the home router requests and receives an IPv4 address,
which is assumed to be a public one. The home router then configures 6to4 address and network (with 48 bit netmask)
for itself based on the received public IPv4 address. The router advertisement daemon configuration is reloaded and the
home router starts to advertise the created IPv6 network to home services. The IPv6 enabled home services use IPv6
auto-configuration to get IPv6 addresses for themselves and may register their hostname either to the dynamic name
service in the home router or in the Internet. Dynamic DNS registration of the home services is however not required as
also other service discovery technologies can be used to find the services.
From the user terminal perspective the proposed solution does not seem to function any differently than setting up an
IPv4 VPN tunnel to the home network. The terminal first finds out the IPv4 address of the home router and then creates
a VPN tunnel (in our solution OpenVPN) to home router, receives a private IPv4 address for itself, but at the same time
receives also IPv6 address from the bridged home network via home router advertisements and IPv6 autoconfiguration.
The difference is that even when the private IPv4 home network addresses conflict with the foreign network addresses,
the terminal is still able to use IPv6 connectivity to reach the home services as the used IPv6 addresses are unique. An
additional advantage is that in case the home services can be made securely available to public IPv6 Internet, not even
the VPN is needed if terminal is able to gain IPv6 connectivity via 6to4, Teredo or native IPv6.
Home service discovery can be done via DNS or by utilising some other service discovery methods or protocols. By
bridging the home network over IPv4 to the user terminal, the terminal is able to utilise service discovery protocols as it
still would be in the same network as the services.
Implementation
The proof-of-concept implementation was inspired by a presentation in Terena Networking Conference 2005 [6] about
integrating 6to4 functionality to a commercially available low cost WLAN router. By utilising an open source Linux
implementation, OpenWRT [7], on a Linksys WRT54G/WRT54GL platform it was possible to enhance the functionality
of this common WLAN access point/router platform with the required additional features like the VPN and 6to4/IPv6
functionality. All of these additional features were available as packaged software for OpenWRT and could be installed
with the command:
# ipkg install openvpn openvpn-easy-rsa ez-ipupdate ip ip6tables kmod-ip6tables kmod-ipip kmod-ipv6
radvd
Figure 3: The functionality of the proposed solution
The command installed OpenVPN VPN software [8], shell scripts for simple certificate authority (CA), Dynamic DNS
(DDNS) registration client, ip network settings management command, IPv6 firewall management tool and the kernel
modules required for IPv6 firewall, IP-IP tunneling, IPv6 and IPv6 router advertisement daemon. OpenVPN was chosen
as the VPN solution for the concept implementation as it could fill the requirement of bridging the home network over
IPv4 VPN and was available for several terminal platforms. The use of IPSec tunneling was also considered, but the
reasons for its rejection are documented in the Disadvantages chapter.
The remaining part of the implementation required only the configuration of the home router and the VPN software in
the terminals. The DHCP client's script for user definable actions (Example 1) was where the major changes were made.
The script enabled us to automatically reconfigure 6to4 tunnels and home IPv6 network even if the public IPv4 address
of the home router changed.
The IPv6 router advertisement daemon (radvd) already supported configuring 6to4 addresses so the changes to its
configuration (Example 2) were mainly concentrated in increasing the frequency of the router advertisements.
Home router firewall was also configured to let through all IPv6 traffic and the OpenVPN connection, which required
the following changes to the firewall configuration (Example 3).
In addition also dynamic DNS client (ez-ipupdate) was configured to register the home router's public IPv4 address to
dynamic DNS service and OpenVPN was configured to use TCP port 443 for bridging the home network over VPN
connection. TCP port 443 was chosen as it was considered one of the ports, which were unlikely to be filtered in the
networks between the terminal and home router. The DNS and OpenVPN configuration however did not require any
IPv6 related changes so the example configurations are already documented at the OpenWRT/OpenVPN WWW site.
#!/bin/sh
IPBIN=/usr/sbin/ip
ITF=$interface
ADDR=$ip
NO_DOTS=`echo $ADDR | tr "." " "`
HEX_ADDR=`printf "%02x%02x:%02x%02x" $NO_DOTS`
# delete 6to4
${IPBIN} link set dev tun6to4 down
${IPBIN} tun del tun6to4
# setup 6to4
${IPBIN} tun add tun6to4 mode sit ttl 64 remote any local $ADDR
${IPBIN} link set dev tun6to4 up
${IPBIN} -6 addr add 2002:${HEX_ADDR}::1/16 dev tun6to4
${IPBIN} -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1
${IPBIN} -6 addr add 2002:${HEX_ADDR}:42::1/64 dev br0
# restart radvd
kill -HUP `cat /var/run/radvd.pid`
# update ddns
/usr/sbin/ez-ipupdate -c /etc/ez-ipupdate.conf
Example 1: The DHCP client's script for user definable actions (/etc/udhcpc.user)
interface br0
{
IgnoreIfMissing on;
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 4;
prefix 0:0:0:42::/64
{
AdvOnLink on;
AdvAutonomous on;
Base6to4Interface vlan1;
AdvValidLifetime 180;
AdvPreferredLifetime 60;
};
};
Example 2: IPv6 router advertisement daemon configuration (/etc/radvd.conf)
IPv6 accepted
iptables -I INPUT -p 41 -j ACCEPT
# OpenVPN accepted
iptables -I INPUT -p tcp --dport 443 -j ACCEPT
Example 3: Firewall configuration changes (/etc/firewall.user)
Advantages
The proposed solution has several advantages in addition to solving the route conflict problem. One of the already
mentioned is the enhanced IPv6 connectivity, which in addition to reaching home services, can be used to reach and
contact the terminal even if it is located behind network address translations or firewalls. This kind of connectivity can
then be then utilised to build overlay networks without operator support and used to enable applications and services to
communicate with each other over IPv6 without the need for NAT traversal features in them or additional application
level gateway modules in the routers doing the network address translation.
The 6to4 technology utilised in the solution also gives a home user access to a significantly larger routable address
space for home services and devices once again without the need to buy special services from the Internet Service
Provider offering the IPv4 connectivity. The utilisation of the VPN technologies make it also easier to secure the access
to home network services as well as provides means to bridge home networks to terminal or even connect home
networks directly to each other. By utilising bridged VPN many of the services which could not be used over routable
connections can now be made available for terminals wherever they may roam.
Disadvantages
One of the obvious disadvantages for this solution are the capabilities of home router platforms. While open source
projects provide alternative firmwares with sufficient set of features for several different routers, a regular home user
cannot be expected to be able to utilise them without support from vendor or some service provider. One solution to this
problem is to get the technology adopted by either device vendors or service providers offering customised home
routers. This challenge is discussed in more detail in Challenges and future work chapter.
Using IPv6 is still not yet very straightforward, even with the open source solutions. As it was discussed earlier, the
regular IPv6 support in terminals is already mostly there, but is not often tested very thoroughly or integrated to all of
the applications provided by terminal or operating system vendor. For example the reason why bridged OpenVPN was
chosen as a part of the concept implementation, is that most of the IPSec implementations could not route IPv6 over
them and could not bridge the home network over IPSec either. OpenVPN supported bridging home network and IPv6
over it even if it still cannot do IPv6 routing.
Utilising Domain Name Service for home service discovery can also been seen as a disadvantage as it requires Dynamic
DNS registrations, client software and of course working IPv6-capable Dynamic DNS service either in the home router
or in the Internet. Also in the case name service queries are done over IPv4, a route conflict between home and foreign
network may disrupt the service even if the IPv6 connectivity is still working. This disadvantage can be avoided by
utilising other service discovery methods or doing the name queries over IPv6, but it still exists and is definitely one of
the challenges to be solved in future work.
Challenges and future work
The adoption of this solution and technologies will depend on how useful vendors or service providers see to include it
to their products. Regular vendors and service providers probably want to wait until there is a greater customer need.
On the other hand customers do not know about the possibilities before they are shown to them in practice. The best
approach to this challenge is to find a cooperating vendor, or even better, a service provider willing to develop the
concept further and to integrate it to the devices and services they are already offering. This kind of service provider
may be one of the community network builders like Fon[9] or Wippies[10] who are already utilising open source
platforms and are trying to find ways and ideas to offer better service to their users over third party provided IPv4
connectivity.
In the product sense, the technical issues, which need further work or adjustments are the service discovery (via DNS or
other means), IPv6 firewalling and IPv6 IPSec. Service discovery is important for finding the services reliably on any
terminal platform. IPv6 firewalling is a security issue for securing the home network from threats from the IPv6
Internet. IPv6 IPSec is probably hardest one to solve as it requires support from terminal and VPN client vendors, but is
one of the issues to be researched as many of the mobile platforms, including phones, already support at least IPv4
IPSec but not OpenVPN. Fortunately IPv6 IPSec is not a requirement which needs to be filled before the proposed
solution can be deployed or used.
Conclusions
The technologies for enhancing home service connectivity are already available. In the proof-of-concept
implementation we have shown that all these components can be integrated and utilised to build home routers for
present and future home networks. The technical disadvantages and challenges are solvable with further work and the
whole concept is ready to be turned into products and services. The real challenge is to get vendors, service providers
and home users to adopt and use the technology and this cannot happen before some of these parties actually tries to
utilise the solution and finds the advantages and opportunities it offers. As indicated in the Challenges and further work
chapter, one of the issues for further work is to find and convince a vendor or service provider to integrate the proposed
solution in their home router.
References
[1] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear: ”Address Allocation for Private Internets”, IETF
RFC 1918, February 1996. http://www.ietf.org/rfc/rfc1918.txt
[2] S. Cheshire, B. Aboba, E. Guttman: ”Dynamic Configuration of IPv4 Link-Local Addresses”, IETF RFC 3927, May 2005.
http://www.ietf.org/rfc/rfc3927.txt
[3] B. Carpenter, K. Moore: ”Connection of IPv6 Domains via IPv4 Clouds”, IETF RFC 3056, February 2001.
http://www.ietf.org/rfc/rfc3056.txt
[4] Bilhanan Silverajan, Karri Huhtanen, Jarmo Harju: "IPv6 Experiments in Deploying and Accessing Services from
Home Networks", Proceedings of IEEE Asia Pacific Conference on Communications (APCC) 2006, Busan, South
Korea, Aug 31 - Sep 1 2006, ISBN: 1-4244-0573-4.
[5] C. Huitema: ”Teredo: Tunneling IPv6 over UDP through Net work Address Translations (NATs)”, IETF RFC 4380,
February 2006. http://www.ietf.org/rfc/rfc4380.txt
[6] Eduardo Jacob, Juan José Unzilla, Ma Victoria Higuero, Purificación Saiz, Marina Aguado, Javier Santiago: ”A very
low cost wireless IPv6 Access Router”, Terena Networking Conference 2005, Poznan, Poland, Jun 6 – Jun 9 2005.
http://tnc2005.terena.org/programme/presentations/show.php?pres_id=122
[7] OpenWRT Project. http://openwrt.org/
[8] OpenVPN, An Open Source SSL VPN Solution by James Yonan. http://www.openvpn.net/
[9] Fon, WiFi Community, http://www.fon.com/
[10] Wippies, WiFi Community, http://www.wippies.com/
Vitae
Karri Huhtanen (M.Sc.) is a Researcher at the Institute of Communications Engineering at Tampere University of
Technology researching network and connectivity architectures in addition to his Ph.D. studies concentrating in
community networking architectures. He has earlier worked within wireless communications industry in the research
and development departments of equipment vendors and wireless/internet service providers and now leads an Internet
consulting company, Arch Red Oy, concentrating in wireless and wired Internet technologies, services and architectures.
Bilhanan Silverajan is a Research Scientist at the Institute of Communications Engineering at Tampere University of
Technology. He is currently a sub-project manager for the Interconnected Home Broadband Networks (InHoNets)
Project funded by the National Technology Agency of Finland. He obtained his M.Sc. in Computer Engineering from
Lappeenranta University of Technology in 1998. He is also a Ph.D. candidate in Tampere University of Technology.
Active research interests include Network and Device Mobility, Service Discovery and Pervasive Computing, Home
Networks and Supporting Middleware Architectures for Future IP Networks.
Jarmo Harju received his M.Sc. from Helsinki University of Technology in 1979 and Ph.D. in mathematics from the
University of Helsinki in 1984. During 1985 - 89 he was a senior researcher at the Telecommunications Laboratory of
the Technical Research Center of Finland, working with the development of protocol software. In 1989 - 95 he was
professor of data communications at Lappeenranta University of Technology. Since 1996 he has been professor of
telecommunications in the Institute of Communications Engineering at Tampere University of Technology, Finland,
where he is leading a research group concentrating on network architectures and QoS issues.
