Best way to connect to IPv6 when mobile?

[arkanesystems]

At home/the office: a network happily communicating over IPv6, thanks to a HE Tunnel Broker tunnel terminating at its border Cisco router.

On the road: My Surface tablet running Windows RT.

The problem: Getting one to talk to the other.

...since while I can - sometimes, if the stars are right and Shub-Internet recently propitiated - ping back to my network using its built-in Teredo functionality, that's pretty much all I can do with that, and I've never been able to sustain any kind of useful connectivity over it.  Making the issue a little more florid is that the connectivity the tablet will have while I'm on the road is going to be variable, both in IP address, and in kind - everything from local WiFi in various locations to the AT&T Unite hotspot I carry around for when that's not available.

So, my question: what should I be looking at as an effective way to connect over IPv6 when on the road?

(I had contemplated simply setting up another tunnel for the tablet to use and reconfiguring the endpoint address appropriately as my connectivity changed, but alas and alack, the Unite hotspot does not respond to ICMP on its external address, and since I'm going to be using that a lot, that option seems to be mostly off the table.)

Alistair

[kasperd]

...since while I can - sometimes, if the stars are right and Shub-Internet recently propitiated - ping back to my network using its built-in Teredo functionality, that's pretty much all I can do with that, and I've never been able to sustain any kind of useful connectivity over it.

When Teredo fails in most cases it is due to the Teredo relay being unreliable, perhaps it is overloaded. The good news is, setting up your own Teredo relay is not that hard.

When your Teredo client is communicating with your network at home, you will be relying on the Teredo relays provided by HE. In my experience, that is the least reliable part of the HE service. If you configure Teredo relays on your border routers at home and at the office, then those will be used instead of those provided by HE. (The way Teredo works, the relay closest to native IPv6 host will be used for communication in both directions).

I don't know how easy it is to configure a Teredo relay on a Cisco router. But if you can manage to get that done, then I am almost certain, it will help with the stability problems you have experienced.

To test your Teredo relay, you can use my test page on http://test-ipv6.netiter.dk/ from a browser at home (or the office). If your Teredo relay is functional, that page will tell you the address of the Teredo relay, you are using. Currently it should be telling you the IP address of the HE Teredo relay.

[qbot]

hmmm, I'm a winner 4/4! lol... i setup 6to4 relay on my cisco router, and Teredo relay on Native IPv6 Linux box (miredo). Can also run teredo relay on windows, but not on cisco router, instead router routes the teredo traffic 2001::/32 to native IPv6 address of the linux server.

[kasperd]

i setup 6to4 relay on my cisco router, and Teredo relay on Native IPv6 Linux box (miredo). Can also run teredo relay on windows, but not on cisco router, instead router routes the teredo traffic 2001::/32 to native IPv6 address of the linux server.

In order to guarantee reliable operation the Teredo relay need a public IPv4 address. In theory it can also work reliably by forwarding a single UDP port from the router to the Linux box. However I have no experience with such a setup.

I can only imagine it will get more reliable by specifying a fixed UDP port number in miredo.conf and explicitly forward that UDP port from the router to the Linux box. Here is an example miredo.conf file, which I have been using:

Code Select Expand

# Please refer to the miredo.conf(5) man page for details.
InterfaceName   teredo
RelayType relay

# Pick a Teredo server:
#ServerAddress  teredo.ipv6.microsoft.com
#ServerAddress  teredo-debian.remlab.net

# Some firewall/NAT setups require a specific UDP port number:
#BindPort       3545
BindPort        64646

[kasperd]

In order to guarantee reliable operation the Teredo relay need a public IPv4 address.

I just realized I have been replying to two different people in this thread. Apparently one of which is using a tunnel and the other is using native IPv6.

Checking the log on the server running the IPv6 test, I found the later has been using a setup where browser and relays are using three different IPv4 addresses from a /18 allocation.

I assume these are your addresses, in which case the Teredo relay is probably already on a public IPv4 address.

Code Select Expand

Browser on xxx.xxx.191.100
6to4 relay on xxx.xxx.177.8
Teredo relay on xxx.xxx.128.8:3545

[qbot]

Another thing to note is that ping only uses the teredo server not relay, are you pinging the tunnel addresses? or the teredo ones of office/home PCs? teredo to teredo only uses the server as well. teredo to native (tunneled but still native addresses) would use the relay for traffic other than ping.

When even the ping fails you may be running into double-nat/double-frewalling/or Carrier Grade NAT on cell networks which is quite common (those address you weren't able to ping were they 10.X or 100.X addresses?).  For those you may have to switch to another tunnel provider that does not use 6in4 protocols, but instead a more NAT friendly one like TSP. see:
http://en.wikipedia.org/wiki/Tunnel_broker

[kasperd]

Another thing to note is that ping only uses the teredo server not relay

That's not entirely accurate. The Teredo client will generate some echo requests on its own, and those are sent through the Teredo server. However the echo replies will be sent through the Teredo relay.

When you use the ping command to generate the echo requests, the Teredo client could send those through the server, but that would not be the usual way of doing it. Rather a typical approach would be for the Teredo client to generate a different echo request and send that through the server. The echo request from the ping command would be queued until a tunnel has been established to the relay. At that point the echo request from the ping command would be send through the tunnel to the relay.

teredo to teredo only uses the server as well.

In that scenario I believe the servers are only used for NAT hole punching between the clients. If NAT hole punching fails, I don't think it will be possible to communicate between the Teredo clients.

Address selection algorithms are often not aware of this limitation, and may actually prefer Teredo to Teredo communication due to longest common prefix matching. Due to that I recommend against servers on Teredo addresses, except for testing purposes. In other words, don't put any 2001::/32 address in an AAAA record on any important domain.

When even the ping fails you may be running into double-nat/double-frewalling/or Carrier Grade NAT on cell networks which is quite common.

On such networks a Teredo client should still be able to communicate with peers using native IPv6 or even 6to4. Teredo to Teredo communication is however unlikely to work. Running 6in4 or 6to4 on such a network has little chance of working. Overall the most reliable IPv6 connectivity on such a network would be some IPv6 over UDP tunnelling protocol through a tunnel provider. (Unless you can get native IPv6 of course). If you are on such a network the best options for tunnel providers might be SixXS and gogo6.

If you only need to communicate with peers, which have their own Teredo relays, then Teredo is the more reliable option.