I did everything below on one of the example Linux instances supplied by Amazon, with an elastic IP address attached.
The first approach I tried was using 6to4 - a protocol which automatically gives anyone with a static IPv4 address their own range of IPv6 addresses. In another blog post, I described how to get 6to4 running on Linux in 5 command lines. I ran those commands on my EC2 instance and end up with my own IPv6 address.
There were, however, some reachability problems. Its not clear to me how much of that comes from EC2 (for example, I tried to disable their firewall as much as possible, but its not clear how disabled it is), and how much it comes from the flakiness of 6to4. (see, for example, that Google doesn't support ipv6 over tunnels).
I have two IPv6 hosts already, one on 6to4 (P), one with native connectivity (D).
I can ping from my EC2 host to my own host P. Pinging from P to EC2 gives no response *until* I start a ping from EC2 to P, in which case I start getting responses. That makes me think very much that Amazon is running a stateful firewall for protocol 41 that allows traffic back in once something has been sent out, for any particular IPv4 address.
I cannot ping at all between D and EC2, in either direction.
From this online ping tool I can ping my EC2 instance OK.
The second method I tried is a manually configured tunnel via Hurricane Electric. HE have been around a long time and have a good reputation (and who I used before years ago). The configuration is a set of fairly straightforward web forms. I allocated a /64 (even that is excessive - I only need a single IPv6 address for this host)
The web form also gives example configuration instructions for a variety of platforms - The
Linux-net-tools instructions are the ones I want. I pasted the 4 given commands literally into a root prompt on my EC2 machine, and that was all I needed for my machine to be connected (at least until reboot).I see similar "stateful firewall" behaviour as I mentioned above, but they difference is that that is only be between me and the HE tunnel endpoint - as long as *anything* goes over the tunnel, then connectivity with the entire IPv6 world stays up. And when that tunnel is up, the connectivity from machines D and P seem *much* better. As in: I can ping both ways without any mysterious losses. So it looks like I'll need a ping to the tunnel endpoint (or anywhere, really) every minute or so. That's no big deal - I have MRTG set up to measure some ipv6 latencies anyway, and that suffices.
So HE is a little bit (a few web forms) more effort to set up. But the connectivity is much much better. I recommend HE over 6to4 for this.
Other links: aco wrote about getting IPv6 on EC2 using sixxs, and if you're interested in getting a shell account on this machine to try for yourself: www.barwen.ch
Modified: 2011-04-19 Rephrasing a bit based on ongoing experience, and some more hyperlinks
Posts
Another option is Miredo which uses a single UDP port. Even without security group, client will puncture a hole on NAT by itself. It seems work for me.
ReplyDeleteI guess the reason why 6to4 sometime doesn't work is probably due to different return address from multiple address host which may use a native 6to4 return path.
Miredo should work fine for outbound/client-like access (although I haven't tried it in EC2, I use it elsewhere, and it sounds like you have). But it gives you a different ipv6 address for every miredo initialisation (because the UDP port used for the connection is encoded into the generated ipv6 address). (unless maybe the miredo client has an option to force the same port to be used every time, but I didn't see one).
ReplyDeleteThat frequently changing IP address makes not as suitable for a server environment.
I agree with your diagnosis of 6to4.
oh I see miredo has a 'BindPort' config option which might allow the UDP port to be fixed (the OS X repackaging of Miredo that I use doesn't have that option exposed in its config GUI.
ReplyDeleteAlso, you get no reverse DNS with miredo. I really should get round to finishing off my draft posting comparing different tunnelling methods.
ReplyDeleteTeredo address always has 12 random bits even when UDP is fixed.
ReplyDeleteHi thanks for linking to my article, I prefer SiXS :) only because I used them for a long time on a number of hosts, and have a POP realy nearby (3 msec RTT). Recently I've switched to HE for my home setup (i have an Airport Extreme Base Station which works with HE tunnels), so'l I'll check out how well they do.
ReplyDelete