Unexpected benefits of IPv6 tunnelling

by Oliver on Thursday, December 26th, 2013.

Recently I wrote about getting my IPv6 tunnel setup working properly again after a while of it not working very well (or not at all). Since my ISP doesn’t yet (to my knowledge) provide native IPv6 connectivity to regular consumers, I tunnel IPv6 via Hurricane Electric, which on the whole works pretty well.

Another fantastic thing that my ISP does is throttle YouTube (and presumably other) traffic, which can make it unusable at the best of times, even at the lowest resolutions. I’m being sarcastic, obviously – it’s REALLY irritating. YouTube, GMail and presumably many other Google services as well as other mainstream sites such as Facebook have supported IPv6 for some time by default and the range of sites supporting it is fortunately increasing (although not nearly fast enough). After getting my IPv6 running properly again, I noticed that YouTube videos were actually starting quite fast and playing back without interruption.

Presumably Deutsche Telekom is doing some fairly basic packet inspection or identification of YouTube flows based on Autonomous System numbers or known IP subnets, as the tunnelled traffic via IPv6 is not throttled it would seem. Despite being re-routed via Frankfurt and suffering a small additional latency penalty, I still get vastly superior YouTube performance over the IPv6 tunnel as opposed to regular IPv4 transit. Especially given that the much smaller IPv6 routing table is often not nearly as optimised as the vast number of IPv4 routes, this is pretty impressive.

So in actual fact I’m currently better off with my tunnelled IPv6 connectivity than having native IPv6 connectivity through Deutsche Telekom. Odd, but currently very satifying.

Tags: , , ,

Thursday, December 26th, 2013 Germany, Tech No Comments

UPnP, IPv6 and updater scripts

by Oliver on Saturday, December 21st, 2013.

I’ve written a couple of times in the past about my use of IPv6 at home. Sadly the state of native IPv6 for consumers is not so much better, so I’m left without native connectivity to my router (to be fair, I have assumed nothing has changed but it is possible Deutsche Telekom is now offering it without making any fanfare about its arrival).

So I still have the humble Hurricane Electric tunnel running as I’ve previously written about. Unfortunately the tunnel config at the HE end needs to be updated whenever your public IP changes (which it does almost every day), and I’ve only ever managed this by hacking up the DynDNS support in my router. This also meant that I couldn’t use any actual DynDNS updating in conjunction with the hack. For a time I had some kind of DynDNS client running on my HTPC but that also seemed somewhat unreliable.

Irritated with the poor state of this system, and looking to do a little bit of programming in Go, I set about building a small program that does the following:

  • Retrieves the current WAN IP from the router using Universal Plug ‘n’ Play.
  • Calls the Tunnelbroker API to update the configuration with the current WAN IP.
  • Profit!

Prior to this I only had an extremely cursory knowledge of UPnP, i.e., some technology in the router vaguely associated with Microsoft that introduces security holes into your network and is best left disabled! It is actually a very rich system of protocols that facilitates automation, integration of a wide variety of different devices and evented reactions to system changes. You can read through this guide to understanding UPnP which explains the intentions behind it, and a little of a (now slightly dated) vision of the future electronic home – despite it only being written in 2000.

My purpose is much simpler – grab the WAN interface IP address. Sure, I could do this with curl hitting one of the many “what is my IP”-style websites, but that requires actually going out onto the internet and making a request to some random site when my router already knows the address. It seems far more logical to retrieve it from there directly! Fortunately this is dead simple with UPnP, once you understand the general command flow and protocols/requests to use. Briefly, the exchange looks like this:

  • Send multicast UDP discovery message to the network. The message is basically an HTTP request.
  • Router responds with search results for each service it provides, via unicast UDP to the host that sent the discovery message. The responses again are basically HTTP.
  • Send an HTTP request over TCP this time to the router’s control endpoint with a SOAP/XML request asking for the IP address.
  • Router sends the HTTP response back with XML containing the IP address.

I can happily say that this works, and you can browse the code here. Pull requests and issues welcome. Making the subsequent HTTP request to the Tunnelbroker API is relatively straightforward, after the UPnP gymnastics.

In this implementation I just make a single control request to the router, and get a single response back, but I mentioned earlier that a core feature of UPnP is evented responses to system changes. The overview document I linked to above mentions such things as a program running on your computer that responds to events from the printer advising it is out of paper, or that its physical location has changed, but the possibilities here are really as limitless as the devices that can support UPnP. In this case, it is possible for the router to update subscribers about a new IP address once it has changed (which sadly I haven’t yet implemented).

So in summary, UPnP is a surprisingly useful technology that deserves looking into. If you have a use for my tunnel updater program, I’d love to hear any feedback on it.

Tags: , ,

Saturday, December 21st, 2013 Tech No Comments

IPv6 Privacy

by Oliver on Sunday, September 12th, 2010.

I’m a big proponent of getting IPv6 out there, but not everyone shares this opinion. A lot of people are happy to stick with IPv4 and all of the horrid NATing nightmares this introduces despite there being such big wins when using IPv6. Some issues it does introduce though need to be dealt with:

  • The big compatibility issue, which encompasses OS, network stack and application support as well as support by all of the solid-state devices out there already.
  • Direct-connectivity to all endpoints is now possible, so NAT cannot be relied upon to provide security.
  • MAC addresses are directly converted into EUI-64 addresses which, when used with IPv6 autoconfiguration, are directly exposed in the IPv6 address.

These last two seem to cause a bit of argument. NAT does provide an implicit form of security (albeit one that can be bypassed with advanced techniques). Adequate firewalling mitigates the security problem, and doesn’t involve breaking the Internet. The alternative is working with an Internet where NAT is omnipresent and every P2P service requires proxies or connection brokering services. This will be a problem.

The last point of MAC address privacy is easily dealt with. If you (like me) don’t particularly find the idea of exposing your MAC address to the world when you use IPv6, you can configure your system to randomize the address. Setting:

net.ipv6.conf.all.use_tempaddr = 2

will cause your network stack to use the advertised prefix on your segment but generate a random suffix, and use it as the preferred address (any previously configured address from the MAC address will be deprecated and eventually removed).

Tags: , ,

Sunday, September 12th, 2010 Tech No Comments


by Oliver on Sunday, September 12th, 2010.

One last post before I hit the sack… There’s this thing called IPv6. You need it.

By and large most companies involved in Internet things are doing very little to promote IPv6 uptake but Hurricane Electric are one of few that are doing some cool things. They offer free IPv6 tunneling (and have a lot of endpoints globally), as well as a pretty awesome certification course. OK, it’s not “official” but to get through it you actually have to demonstrate some real practical knowledge of IPv6.

I myself have now got my own domain hosted on their nameservers and will shortly add some quad-A records (my previous certification attempts only got so far after I discovered the dynamic DNS service I was using for it out of convenience didn’t have quad-A records for their nameservers).

Check out HE’s offerings:

I should also thank Kai from work, whose loaned Seagate Dockstar is my IPv6 endpoint 😉

Tags: ,

Sunday, September 12th, 2010 Tech No Comments