Setup Raspberry Pi IPv6 Gateway with Router Advertisement Daemon
A Raspberry Pi is supposed to make IPv6 available on a local network as a gateway. To do this, Raspberry Pi must be set up as an IPv6 tunnel endpoint. The starting point is that you have a 6in4 tunnel from SixXS and want to make the over Raspberry Pi available to all other participants. Raspberry Pi is set up as an IPv6 gateway, which passes its assigned prefix to the other IPv6-enabled participants.
Note: Please note that the operation of an IPv6 gateway must include an IPv6 firewall, otherwise the IPv6 clients will be unprotected connected to the Internet.
Task:
- Turn on IPv6 forwarding on Raspberry Pi.
- Set up a service that passes the prefix to the local network via Router Advertisement.
- Check the other nodes in the local network to see if they have generated a global IPv6 address from the prefix.
- Check if IPv6 connectivity is possible with these participants.
- Install a name server for name resolution with IPv6.
preparation
For the following solution to work, Raspberry Pi needs to be IPv6 capable and it must already be configured as the endpoint for a SixXS tunnel.
Solution: Turn on IPv6 routing
First you have to turn on IPv6 forwarding. This will cause the Raspberry Pi to route the IPv6 packets between the LAN and the SixXS tunnel. This requires a configuration file to be changed.
sudo nano /etc/sysctl.conf
Here you look for the following line, set the value after the equals sign to “1” and remove the “#” at the beginning of the line.
net.ipv6.conf.all.forwarding = 1
Then save and close the file: Ctrl + O, Return, Ctrl + X.
To apply the setting, we recommend a reboot. You can skip this at this point too, because a reboot will be necessary later.
sudo reboot
After the restart you have to give the Raspberry Pi a fixed IPv6 address from the subnet assigned by SixXS. To do this, we open the configuration file with the network settings.
sudo nano /etc/network/interfaces
There we also add the following minimal configuration:
# IPv6
iface eth0 inet6 static
address 2001: db8 :: 1
netmask 64
The IPv6 address used here must be replaced by an address from its own subnet. It is important that the IPv6 address is chosen from the “Subnet Prefix” and not from the prefix of the tunnel!
The IPv6 gateway needs a static IPv6 address for routing to work.
Then save and close the file: Ctrl + O, Return, Ctrl + X.
In order for the setting to be adopted, a reboot should now be made.
sudo reboot
After the reboot, it does not hurt if you check with “ifconfig” briefly whether the Raspberry Pi has assigned the fixed IPv6 address. It should be assigned to the interface “eth0” with the note “Global”.
Solution: Distribute prefix in the local network (Router Advertisement)
In order for Raspberry Pi to act as a gateway, it must distribute the assigned prefix (subnet) in the local network via router advertisement. The Router Advertisement Daemon “radvd” is suitable for this, which must be installed and then configured.
sudo apt-get install radvd
After installation, “radvd” must be configured.
sudo nano /etc/radvd.conf
The following minimal configuration is entered in the empty file:
interface eth0 {
AdvSendAdvert on;
AdvLinkMTU 1280;
MaxRtrAdvInterval 120;
prefix 2001: db8 :: / 64 {};
AdvSourceLLAddress on;
};
Here the prefix must be replaced by its own prefix. It is important that you enter the “Subnet Prefix” assigned by SixXS with the default netmask “/ 64” as “prefix” and not the prefix of the tunnel!
Then save and close: Ctrl + O, Return, Ctrl + X.
After the changes to the configuration file you have to start the daemon manually.
sudo service radvd start
If the daemon is already running, it is necessary to restart the daemon.
sudo service radvd restart
Now you can try from another computer to access an IPv6-enabled server. For example, with the browser on https://test-ipv6.com . Here you can also test your own connectivity for IPv6 capability.
If that does not work, so there’s no IPv6 capability, it’s usually because “radvd” has the wrong prefix. Typically, one has confused the prefix of the tunnel with that of the subnet. Although these prefixes are similar, one has to differentiate here.
Solution: Nameserver (optional)
What is missing is a name server for IPv6. For this we use “unbound”. It is useful for name resolution and caching of results. The delivery of zone data, however, is very limited. As recommended rather “bind9”. But this is a different house number and completely oversized for the purpose of an IPv6 gateway.
sudo apt-get install unbound
After successful installation, it is time to configure.
sudo nano /etc/unbound/unbound.conf
Here you enter the following lines as minimal configuration:
server:
verbosity: 1
interface: :: 1
interface: 2001: db8 :: 1
port: 53
access-control :: 1/128 allow
access-control: 2001: db8 :: / 64 allow
Here is the note that we want to answer both on the gateway, as well as from the local network DNS request. Therefore, the specification for the “localhost” and the global prefix is required.
Both the static IPv6 address of the gateway (interface) and the own prefix (access-control) must be used here. When working with a SixXS tunnel, it is important to enter the Subnet Prefix assigned by SixXS, not the prefix of the tunnel!
Entering the link-local IPv6 address or the link-local prefix with “fe80” is not useful at this point. Then “unbound” will not work.
Then save and close: Ctrl + O, Return, Ctrl + X.
For the settings to be adopted, a restart of the name server is necessary.
sudo service unbound restart
The status of “unbound” is checked as follows:
sudo service unbound status
Of course we want to know if it works. For this we test the name server with a name resolution.
host www.google.com :: 1
The result should be a list of multiple IP addresses. Including IPv4 and IPv6 addresses.
We do not know yet if our name server works. For this we look at which name server is entered in the IP configuration:
cat /etc/resolv.conf
Here should be a line with “nameserver :: 1”. If not, then you have to help a little. For this we install “resolvconf”.
sudo apt-get install resolvconf
Then we do a name resolution again, execute “resolvconf” and look again at the file “resolv.conf”.
host www.google.com :: 1
sudo resolvconf -u
cat /etc/resolv.conf
Now “nameserver :: 1” should be entered. If not, then anything about the overall configuration of the system is lazy.
In principle, you can also manually write the name server into the configuration file. However, this is pretty pointless because the contents of the file are automatically overwritten.
If it is ensured that “unbound” works locally on the gateway, then you still have to worry about distributing the name server address. This is done via Router Advertisement together with the prefix with the RDNSS option. To do this we need to change the configuration file of the Router Advertisement Daemon.
sudo nano /etc/radvd.conf
Here you add the following lines before the closing bracket of “interface etho {“
# Announce DNS server
RDNSS 2001: db8 :: 1 {};
Here the IPv6 address of the gateway should be entered. The global, not the link-local IPv6 address. Some operating systems do not accept a link-local name server address.
Then save and close: Ctrl + O, Return, Ctrl + X.
In order for the settings to be adopted and the address of the name server to be distributed, the router advertisement daemon must be restarted.
sudo service radvd restart
After the restart, the IPv6 gateway is completely set up.
Troubleshooting: If the IPv6 gateway does not work
As a rule, the IPv6 gateway will run through several weeks and months without any problems and thus without supervision. If it does not work or does not work properly, you usually will not notice it because IPv4 is running alongside it. As a rule, a problem will only be detected if IPv6 is no longer used in typical IPv6 remote sites.
If the gateway does not work properly, the easiest case is a restart.
sudo reboot
If the IPv6 gateway does not work, ie no IPv6 connections are possible, then you should check the interfaces on the gateway.
ifconfig
There must be 4 interfaces by default: eth0, lo, sit0 and sixxs. If one is missing, then something is wrong. eth0 and lo will always be there. The sit0 and sixxs interfaces are virtual interfaces for the tunnel. They are set up by “aiccu”. If one of them is missing, then of course the gateway can not work.
The status of the tunnel service can be read as follows:
sudo service aiccu status
Maybe a restart of the tunnel will help:
sudo service aiccu restart
If that is not the solution, then you should check if the clients got global IPv6 addresses from the RA daemon. If not, then check the status of the RA daemon.
The status of the RA daemon is learned as follows:
sudo service radvd status
Maybe a restart helps:
sudo service radvd restart
Basically, you should make a reboot after a restart of the RA Daemon. Only then you can be sure that the gateway works properly even after a reboot. A restart can also be caused by a power failure.
Under certain circumstances, the name resolution does not work.
The status of “unbound” is checked as follows:
sudo service unbound status
Maybe a restart helps:
sudo service unbound restart
You should also check whether the system has adopted the correct name server.
cat /etc/resolv.conf
Here should be a line with “nameserver :: 1”. If not, you have to help a lot by hand.
sudo resolvconf -u
If the IPv6 gateway causes problems on the network, then you can simply take it out of service and check if the network works without a gateway. To do this, put the RA daemon out of service.
sudo service radvd stop
However, the gateway does not necessarily have to deal with network problems, but one component less, one source of error is less. If the network does not work properly even without a gateway, then you have to search the local network. If they are fixed, then you can put the IPv6 gateway back into operation.
sudo service radvd start
A reboot is recommended.
sudo reboot
Then check the IPv6 gateway services.
sudo service aiccu status
sudo service radvd status
sudo service unbound status
cat /etc/resolv.conf
Note about the name server
Unfortunately, some operating systems do not know the RDNSS option. With these operating systems, you would have to statically set the name server or install the RDNSS option later.
The fact that the RDNSS option is missing on some clients plays no role in a dual-stack environment (IPv4 and IPv6 in parallel operation). Only in a pure IPv6 environment, each client must support the RDNSS option or get the DNS server assigned via DHCPv6.
It is sufficient if the clients are assigned the address of the DNS server via DHCPv4. For this reason one can do without the installation of the nameserver for IPv6. For name resolution, the client then simply uses IPv4. In doing so, he gets back the IPv4 address and, if available, the IPv6 address. If the client has a global IPv6 address, he will connect via IPv4 or IPv6.
However, an IPv6 gateway without its own name server is a rather incomplete solution because it does not allow pure IPv6 connectivity. For the name resolution is still necessary IPv4. That is a bit unsatisfactory. That’s why a name server makes perfect sense for IPv6.
Note about the IPv6 gateway
Raspberry Pi is a cheap all-round talent that you can “abuse” for many things. Especially as a gateway or server in your own LAN. It should be noted that, depending on the model, the hardware has limits. In addition, the Raspberry Pi has no separate Ethernet interfaces for incoming and outgoing traffic, but only one through which the data packets go in and out. Here you should expect no speed miracles.
The limited hardware performance naturally has consequences for the use of the IPv6 tunnel. The dual-stack (IPv4 and IPv6 in parallel operation) of the clients will use IPv4 and IPv6, respectively, thanks to the global IPv6 address. However, this is usually preferred, which provides the better connectivity. Speed plays a role as well. If the IPv6 tunnel over Raspberry Pi is too slow, then a client will usually prefer IPv4.
What you should know is that in this constellation you should do without updates via “apt-get upgrade”. It may happen that after that the gateway does not work properly or not at all. In such a case you have to take a lot of time for troubleshooting and possibly make a new set up.
Note about the IPv6 tunnel
Operating an IPv6 tunnel is always slower than native IPv6 and may cause additional problems. So you should not assume that whenever IPv6 is possible always IPv6 is used. It is not so. A client will always opt for the IP in a dual-stack environment that provides better connectivity. And that does not tend to be the case with an IPv6 tunnel. If the IPv6 tunnel is too slow, then a client will usually prefer IPv4.
Despite all limitations and possible problems, you can operate the solution shown here in practice permanently. However, an IPv6 tunnel is “always” a temporary (emergency) solution that should eventually be replaced by a dual stack (IPv4 and IPv6 in parallel) with native IPv6.
Security Notice for the IPv6 Tunnel
Attention! With the operation of an IPv6 tunnel, “every computer in the LAN” can be reached worldwide with its own global IPv6 address. Everyone can access these computers externally if an IPv6 address is known from the LAN. It is no longer the case that you can hide behind a router as with IPv4 NAT. This means that you have to make sure that on Raspberry Pi as a tunnel endpoint a properly configured firewall is active.
Leave a Reply