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.
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.
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.
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).
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 😉
- February 2017
- January 2017
- December 2016
- October 2016
- August 2016
- June 2016
- May 2016
- August 2015
- June 2015
- April 2015
- March 2015
- January 2015
- December 2014
- November 2014
- August 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- July 2013
- June 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- November 2010
- October 2010
- September 2010