Forwarding protocol 41 (6to4) to a Linux box

ipv6routing

I have a Linux router without an ipv6 stack and a Linux host inside the NAT. How do I use iptables to forward 6to4 traffic back and forth between the NAT router and the host and then configure the 6to4 tunnel on the host using the router's public IPv4 address?

This recipe (on the router) gets an ipv6 ping to the host's eth0 but they don't make it onto the tun6to4 interface. Wireshark says "ICMP Destination unreachable (Port unreachable)" as an ipv4 response to the 6to4 ping.

# inbound destination NAT for IPv6 tunnel. ppp0 is router's WAN interface.
iptables -t nat -A PREROUTING -i ppp0 -p 41 -j DNAT --to 192.168.1.100
# inbound forwarding for IPv6 tunnel
iptables -t filter -A FORWARD -i ppp0 -p 41 -d 192.168.1.100 -j ACCEPT

I am using this script on the Linux host, passing the router's public ip:

#!/bin/bash

### Get the global IPv4 address for your host from the command line:
GLOB_IP4=$1

### Compute the 6TO4 tunnel IPv6 address:
GLOB_IP6TO4=$(printf "2002:%02x%02x:%02x%02x::1" $(echo $GLOB_IP4 | tr . ' '))

### Setup the tunnel
ip tunnel add tun6to4 mode sit remote any local $GLOB_IP4 ttl 64
ip link set dev tun6to4 up
ip addr add $GLOB_IP6TO4/16 dev tun6to4
ip route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1

Best Answer

iptables -t nat -A PREROUTING -d 192.0.2.75 -p 41 -j DNAT --to 10.0.0.2 on the router should do the trick, assuming that all flows are initiated from outside to your IP address (given as 192.0.2.75 in this example). If your IPv6-capable box starts things, then regular catch-all SNAT rules should do the trick.

Related Solutions

Linux – Can a Linux router autoconfigure IPv6 if radvd is running on the same host

The short answer: On a system that you are running radvd on, you want to configure the interface using the same method as you use to configure radvd; if radvd.conf is statically generated, then so should your local Ethernet interface's IPv6 address be statically generated. But, all is not lost; read on for more detail.

What you can do is use a small shell script to configure both. Let's say for a moment that you have a dynamically assigned global IPv4 address, and this is the only IPv4 address on your interface; you can use the following shell script snippet to obtain the IPv6 /48 prefix (note: code adapted from ARIN:

IPV4=$(ip addr ls eth0 | grep 'inet ' | awk '{ print $2 }' | cut -f1 -d/)
PARTS=`echo $IPV4 | tr . ' '`
PREFIX48=`printf "2002:%02x%02x:%02x%02x" $PARTS`

Now, you have the /48 prefix; getting a /64 prefix is simple enough, since you can just append it to the $PREFIX48 variable.

Now, all that would be left for you to do is write the script that writes out the network interface configuration and radvd configuration (presumably, from a template for each of them) and make that script run before your network configuration does. I'll not be including that code here as I do not know what distribution you are using, and it differs depending on that.

Hope this helps.

Connectivity between IPv6 Teredo host and IPv6 6to4 Host

6to4 is known to be unreliable, and Teredo is even worse. When you communicate between 6to4 and Teredo you get all the problems of each combined plus a few more due to complex interactions between the protocols.

Thus it may come as a surprise to you that the answer is: Yes, you can get reliable communication between 6to4 and Teredo.

Both protocols suffer from the same main problem. They rely on third party relays which are underprovisioned and due to their third party nature come with no SLA.

Teredo uses one relay for both directions. 6to4 usually uses two for different directions, but due to the triangular routing in Teredo you end up depending on three 6to4 relays rather than just two. That is a total of four third party relays which you will be depending on - all of which must have enough capacity for your traffic.

But you don't have to rely on third party relays. You can set up your own relay.

Setting up your own Teredo relay

The Teredo relay is the simplest to set up, and it happens to be the most important to your scenario. A Teredo relay needs a single UDP port on a public IPv4 address. Thus you should not deploy the relay on the LAN behind your D-Link router. You should avoid having any 6to4 relay/gateway on the path between your LAN and the Teredo relay. Thus you should not deploy the relay outside the D-Link router.

In short you need a Teredo relay on the D-Link router to make connectivity work reliably. If the D-Link cannot run a Teredo relay, your best option is to replace the D-Link router with a router which can run a Teredo relay. In my experience it will work reliably if you use a Linux machine with Miredo configured in relay mode for the router.

Deploying your own Teredo relay on the D-Link router would not only mean that you no longer rely on a third party Teredo relay. It will also give you a native path between your Teredo relay and your LAN, thus you avoid two of the three third party 6to4 relays as well.

What's left

You would still be relying on a single third party 6to4 relay. A Teredo client need to choose which Teredo server it will be using. The two Teredo clients I know of each have a default configured which will be used if you do not change the configuration yourself. The network path from the Teredo server to your D-Link router will have to pass through a 6to4 relay.

So what you need to do is to choose a Teredo server with access to a reliable 6to4 relay. Ideally a 6to4 relay should be configured on the machine running the Teredo server.

Is this a recommendable configuration?

Installing a Teredo relay on your router is definitely a reliability improvement as long as your router has a public IPv4 address. It will give a significant reliability improvement for any communication with Teredo users, and it will not have any impact on other communication. This is true regardless of whether your router is doing 6to4 or native IPv6.

Using 6to4 on your LAN is however not recommendable as many networks have not installed any 6to4 relays. Hosts on your LAN would often face problems communicating with hosts with native IPv6.

Using a Teredo client is not recommendable either due to all the same reasons that 6to4 isn't. However there are a few cases where Teredo can be useful. Most importantly a Teredo client can connect to hosts on the LAN behind your router (assuming your router has a Teredo relay). And sometimes I have come across CGN deployments working so poorly that Teredo through the CGN is more reliable than TCP through the CGN.