1

I'm working at a project at my university and now the following problem shows up:

We got a Server [Server] with a private IPv6 network. Some sensors (temperature, humidity...) are connected through a router and they've got own private IPv6 Adresses within this private network).

Server A is connected to the Intranet of the university. The intranet does not support IPv6, but IPv4.

My own computer [Client] is able to reach the Server via VPN and IPv4.

Now I want to get the status of the sensors on the Client. Server and Client are using a debian-based OS.

(Internet <-->) Client <--(IPv6 over) IPv4, VPN--> Server <--IPv6--> Sensor

I was thinking about configuring a simple 6to4 tunnel, but without Internet connection the Server can't access the next 6to4 Router (192.88.99.1).

Is there any possibility to configure 6to4 "locally" or do I need an Internet Connection?

What else could I do to get a working connection?

Thank you very much for all help! (and special thanks to Sander, I hope this is the right place to ask my question :) )

2 Answers 2

2

What you want is not 6to4 but 6in4, also known as protocol-41. 6to4 is to allow devices with an internet connection with a public IPv4 address to get IPv6 access. It is a protocol with serious stability issues and shouldn't be used anymore. With 6in4 you can manually configure IPv6-in-IPv4 tunnels.

You can configure a 6in4 tunnel on Debian/Ubuntu like this:

auto ipv6tun
iface ipv6tun inet6 v4tunnel
    address 2001:db8::1
    netmask 64
    endpoint 192.0.2.111
    gateway 2001:db8:0f10:99d::1

On the end without an IPv6 internet connection you could also add a gateway line, like:

auto ipv6tun
iface ipv6tun inet6 v4tunnel
    address 2001:db8::2
    netmask 64
    endpoint 192.0.2.222
    gateway 2001:db8::1

You should replace the IPv4 and IPv6 addresses with addresses that are appropriate for your network.

PS: RFC7059 is about to be published. It contains an overview of IPv6-in-IPv4 tunneling mechanisms. Disclosure: I am one of the authors.

2
  • 1
    It took a lot of time, but now I've done it. A very important thing I did not know is: the Ipv6 forwarding is turned off in Debian/Ubuntu -.- to test it just use: cat /proc/sys/net/ipv6/conf/all/forwarding it has to be "1" ... another problem: I had some VMWare interfaces...by using ping6 to the sensor it took one of their IPv4 addresses (coded as IPv6)...very strange oO I deleted them and now it works - thanks!
    – Bohne
    Commented Dec 19, 2013 at 14:28
  • Good point: to be able to forward IPv6 packets you indeed need to enable IPv6 forwarding. You can usually do that in /etc/sysctl.conf with the line net.ipv6.conf.all.forwarding=1. If ping6 uses a mapped IPv4 address as source that is usually an indication that it can't bind a 'real' source address, so I don't know why it behaved like you describe. Commented Dec 20, 2013 at 13:15
0

You may be overcomplicating things. If you have (IPv4) SSH access to the server, you can use SSH port forwarding, eg logging into the server with this command:

ssh -L 12345:[2001:db8::6]:4321 <server-ip4-address>

would allow you to contact the sensor (on its IPv6 address 2001:db8::6) on port 12345 on your local machine for as long as the SSH session lasts.

You did not specify how results are to be fetched from the sensors. The above works for TCP. In the case of UDP, you will need to add some socat to the mix, or some netcat and mkfifo if you prefer. ssh -w might also do the trick, haven't tried that yet.

Netcat or socat can also help to create an alternative where you open a socket at the server which will forward the traffic to an internal IPv6 address without having to keep an SSH session open.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .