Finally solving the IPv6 problem

So, after discussing NATs and dynamic host solutions I finally was able to reach a solution, although I would never have been able to without Maxime’s help as I didn’t consider Freenet6 something worth looking at before, while that is my good solution, as it covers all my requirements:

  • it allows to pass through hostile IPv4 NATs through ipv6-over-udp;
  • it provides you with stable addresses (as long as you connect to the same server and you authenticate);
  • it provides not just one address, but a routed /64 prefix which is exactly what I was looking for.

Unfortunately, it isn’t in itself a solution that is totally painless; the first problem is with the software needed to set up the connection. The original freenet6 client was renamed to net-misc/gateway6; when I first installed that one, it failed to start altogether, beside, it reported overflows which I didn’t like at all. I was able to at least cover the overflows and improve a bit on the init script with the 6.0-r2 version (which also respects LDFLAGS). But even that fails badly when you try connecting to the authenticated server.

Bernard found what the main problem was with that: the software changed name again, and also versioning, it is now called gogoCLIENT and the package is named gogoc. With a bit of trial-and-error, I was able to get net-misc/gogoc in tree, for now only keyworded amd64 unstable (I’ll open a keyword request tomorrow, since it’s the upgrade path for gateway6 users). The new software works fine with authenticated servers, but has some trouble with radvd as it tries to configure it itself… pretty much failing to work in a decent way. It’s something I’ll try to fix in the next few days.

Interestingly enough, this version rather than solving the overflows, adds a new one. So once again if you ever experienced crashes with freenet6/gateway6/gogoc (not in Gentoo, the latter) on x86-64 based-systems, make sure to fetch my overflow patches, or start using Gentoo.

So now I have my stable IPv6 tunnel, and I can set up the firewall to let me access the network as I require, again, thanks Maxime!

There are a few more issues that i have to polish down so I can deploy it safely, some that I didn’t even expect I’d find myself thinking of about. The first problem was finding a way to access the boxes on my network while I’m setting it up without going through the whole routing that gogoNet requires me to go through (it skips out through my point of presence for 6to4, go through Frankfurt, Washington, then back to the Netherlands, which is quite silly). Solving the problem is, actually, pretty simple: I still have Quagga installed on my main router, and at a quick test, I was able to get the two RIP daemons to talk to each other so that accessing the network I assigned to my customer (I was careful to choose one that is disjuncted and compatible with the one I’m running locally (although I probably should come back to what they have been using already right now since it’s just as compatible for what I’m concerned ( Tomorrow, I’ll probably set up RIPng as well and that should solve my problems during testing rather than deployment — I definitely hope this is not the last time I do work like this, since it’s actually partly enjoyable once you know how to deal with it.

But then, I got another interesting notion, although that is definitely more out of professional curiosity than actual necessity. Once I have the two network segments both available as IPv6 (with firewall allowing me access just between the two), I can connect from my side to the other (but obviously not the other way around) just by using the stable addresses assigned to the machines, using IPv6. But what about those machines that don’t support IPv6 at all (mostly, printers)? For those, I would need access to IPv4; I can do that with a SSH jump host, but… what about dual-stack routing?

Theoretically speaking, I should be able to connect to :: to connect to an IPv4 address through an IPv6 connection; let’s say I can set up routing with Quagga so that the gateway on my side knows to forward those requests to the gateway on the other side, but then what? Which software component takes care of the translation between IP versions?

Sigh, I wish more SoHo hardware routers provided IPv6 by default, it’ll be making my work much much easier.

4 thoughts on “Finally solving the IPv6 problem

  1. The ::0/96 IP range is used by your dual stack configuration to enable you to connect to both IPv4 and v6 hosts via one socket. For example, if you listen on any IPv6 socket for a connection, then on most platforms this will also listen on all IPv4 sockets. IPv4 addresses will then get mapped as ::0/96 addresses.I suspect that getting connectivity to their IPv4 block will prove difficult, short of setting up some sort of tunnel.


  2. It should have some kind of tunnelling or masquerade-like feature. I’m pretty sure I read about it before, but I haven’t found it looking around for a while.


  3. I have a Cisco/Linksys WRVS4400N, which supports dual-stack natively. It’s a pretty nice machine. It supports RIP, IPv6, SNMP, Syslog, DHCP/DHCPv6… has both a firewall and IDS…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s