News of 2013

SixXS wishes everybody a happy and fruitful 2013!

As in other years, in case of problems don't hesitate to contact us.

According to our usage statistics we have now well over 35.000 active users. We should also be closing in on to 40.000 active tunnels in a few months.

As the statistics show this represents users in 145 countries around the world. And indeed, the Vatican is in the list and it is a real entry, they are utilizing an AYIYA tunnel.

We have upgraded the sixxsd on all the PoPs to the current 2013.03.05 version, thus brand new.

This version was running on some of the PoPs already to resolve some minor issues we encountered and for instance to determine the Airport problems (see also the forum thread for other details).

Because of that issue and to make it possible for users to see this, one new Live Tunnel Status detail is now available that shows a counter and the last source address of ICMPv4 errors received by the PoP in relation to your endpoint address. This counter can indicate when your endpoint is rejecting packets from the PoP, which is what the Airport problem showed. Likely this is also a useful indicator for other setups, eg where the ISP is rejecting protocol-41 packets (though typically if proto-41 is filtered on the ISP level they do not send ICMP either).

Another small update in this new version of sixxsd is the ability to both ping and traceroute the sixxsd daemon itself (see the FAQ for the details). As that address is inside the tunnel/subnet prefix for the PoP it is a good indicator that that prefix is properly routed and of course that sixxsd is working. Though similar can be achieved by tracerouting/pinging the gateway of a tunnel (thus prefix::1).

Of course, like usual, in case of problems, don't hesitate to contact us.

We have finally added a crucial bit of a missing forum feature: Message posting previews.

Thus from now on, when you try to post a message in the forum or file a ticket you will have the option to preview the post. In case there is an error in the markup you will be shown these errors and given the ability to correct them. This should provide a much better forum experience.

This feature was requested in the Make it Better Sub-Forum. Slowly, due to time constraints, we are resolving various outstanding issues that are not of direct operational impact.

Of course, as usual if you have feedback, don't hesitate to bring it up on our contact address, as a ticket or in the Make It Better forums.

Additional to this change, a reply to a message now [quote]s the original message and attributes it in a similar way to what most email clients do it.

Long overdue, but finally implemented, tested and enabled: As of today we have enabled STARTTLS support for our TIC servers available as tic.sixxs.net, which is the default TIC server in AICCU.

When a TIC client, such as AICCU, connects to a TIC server and issues a TIC 'starttls' command the TIC server will now start a TLS session, this way all further communications between the client and the TIC server are encrypted. This is especially important to avoid snooping of the heartbeat password used for both the AYIYA and heartbeat protocols.

AICCU currently has it's 'requiretls' option set to false, one could now enable this by setting it to true to make it require STARTTLS. With the 'requiretles' default of false AICCU would still attempt STARTTLS but the server still had the option to reject this request. This of course allows a transparent upgrade of the server and we are now seeing most TIC sessions performing STARTTLS.

Of course, as usual if you have feedback, don't hesitate to bring it up on our contact address, as a ticket for operational issues or in the Make It Better forums for general suggestions.

Congratulations to His Royal Majesty The King William Alexander and Queen Maxima!
We wish you a grand reign of The Netherlands for many years to come!

We also would like to thank Princess Beatrix for her 33 year long reign as Queen of The Netherlands.

The May 2013 (Issue 229) version of Linux Journal has several articles about the extremely versatile Raspberry Pi.

Amongst other good articles, on the cover the text "Use an RPi as a Low-Cost IPv6 Route and Tunnel Endpoint" is noted. The related article is on page 78 and is titled "Autoconfiguring an IPv6 Access Point with SixXS and a Raspberry Pi" written by Igor Partola It details how one can use SixXS to set up IPv6 connectivity when your ISP does not already support IPv6 using a Pi as the tunnel endpoint and even use it for roaming around taking your IPv6 with you to other networks without having a worry of the tunnel breaking due to the changing address or NAT.

A copy of this edition of the Linux Journal can be retrieved from the Linux Journal FTP server.

NetCologne, the host of the decgn01 PoP, has announced that they are ready to provide native IPv6 over DSL to their customer base.

If you are a current or future NetCologne customer, check their IPv6 FAQ for the exact details.

Since May 2011 we are ratelimiting, informing and then blocking hosts which are connecting repeatedely to our TIC server. We are doing this for two primary reasons:

• Avoiding a DoS on our TIC server (we have seen several clients connecting with several 1000's of connections per second as they where running in a loop)
• Making sure users have proper connectivity (when you restart you lost connectivity)

The latter point might surprise you, but when you see the need to restart AICCU, and thus cause it to connect to our TIC server to fetch the tunnel configuration, you are doing something wrong, likely involving that your connectivity is broken and thinking that an (automated) restart of AICCU solves it.

AICCU implements protocols (heartbeat and AYIYA) that are capable of handling a changing network environment, primarily amongst this is the changing IP addresses. Thus if connectivity is broken, there is something broken in the implementation (could be, though we have no report of current issues) or in the network setup. The network setup is not something that AICCU can resolve, as this typically means that the connectivity between you and the PoP, or further, is broken. Restarting AICCU thus does not resolve that sitation.

It seems though that various people instead of reporting problems still decide that, even though we clearly state in various places to not do so and that one will be blocked, to put some kind of automatic startup script around AICCU.

They test for instance if the PoP is down (unfortunately happens) or if some remote service (ipv6.google.com is strangely popular) is 'alive' for them. Instead of then figuring out what is really broken they just automatically restart AICCU, as the problem is external though, they keep on restarting AICCU, which will never resolve that problem. What does happen in the mean time though is that tic.sixxs.net gets hits by that restart every time. At one point the TIC server even starts rejecting requests (Quick Blocked) but as they are restarting it automatically nobody will see the logs, and thus the TIC server will do a Hard Block completely not serving that endpoint anymore.

Even though we are sending, where possible, an email to people about this problem, they do not fix their set up. We thus have a couple of IPs that are still (after multiple years) hammering on our TIC server having sent multiple millions of requests.

As stated in the FAQ, in case you have a network issue, and you think you need to restart AICCU, please do bring it up on the forums or on our email address so that we can work together on properly resolving this problem instead of you hammering our TIC server and not gaining much.

Geoff Huston presented at the IEPG meeting his findings of ULA in the Wild. He found amongst others that there is a large amount of networks apparently using fd00::/48. We would kindly point people at our very easy ULA prefix generator. Using that, and optionally registering the prefix, allows one to avoid any conflicts at all. As the document also points out, do make sure to firewall these prefixes properly away, as they do make it to the Internet, which is how Geoff measured these. As a responsible network administrator one does conform to BCP-38 which solves a number of potential attacks against your network and prevents these kind of leaks.

We have set a few security related HTTP headers on the SixXS website that should make it much harder for any XSS-related attacks to be succesfully executed.

Of primary importance is the Content-Security-Policy header which protects against any foreign javascript, images or even CSS to be inserted into our site. This did cause us to have to change all the inline CSS style declarations to CSS classes; most of these have been done, GRH is one of the parts where we still have to finish up though.

Additionally we are now setting X-Content-Type-Options, X-Frame-Options and X-XSS-Protection.While these three are mostly Microsoft Internet Explorer related, Chrome also uses them and they might foil a few other possible attacks.

We hope that makes SixXS a little bit more secure. If you have any comments/questions don't hesitate to bring them up in the forums or to contact us at our usual address.

As we are in the era of RFC6555 - Happy Eyeballs our good old using of just the connecting IP address to determine if IPv6 is available to the client is not valid anymore. Now either the Operating System or the browser will pick IPv4 or IPv6 depending on a variety of factors, sometimes even connection to IPv4 and IPv6 addresses in parallel or keeping a history of connection successes to these addresses. The simple trying IPv6 first anymore and then falling back to IPv4 is long gone.

Due to that, our indicator showing that one has IPv6 tends to sometimes be 'wrong', simply as the OS/browser used IPv4, even if IPv6 was available. We therefor opened up our Javascript magic box and have added a simple IPv6 Check to the SixXS tools section.

We have marked it as BETA for everybody to play with, primarily the ISP/ASN/country lookup will follow. For other feature requests/comments don't hesitate to contact us or post in the forums.

We have upgraded our SSL certificate. This new certificate is accepted by every major webbrowser and this means that one does not have to make any changes to your clients anymore to reach the secured version of the SixXS site.

Access to the non-SSL version of the SixXS site now unconditially redirects you to the SSL version.

Thanks goes to Massar Networking for sponsoring this new wildcard SSL certificate from Gandi.

We have tuned our SSL servers per the recommendations given in SSL/TLS Deployment Best Practices by Qualys SSL Labs Amongst others Perfect Forward Secrecy is now thus enabled. This does mean that IE6/8 cannot use our website anymore, but you are running a current browser right? The SSL Server Test gives our servers a grade A rating because of these changes.

We are now also setting the HTTP Strict Transport Security header so that your browser will keep on coming back to the SSL edition of the site (not that it has much of another option due to the forced redirect though ;). Additionally cookies are marked with the "Secure" flag to avoid them from ever being sent in the clear.

If you are using the heavily recommended EFF's HTTPS Everywhere plugin then part of this was already what was happening

The new SSL certificate fingerprints are:
SHA1: 46 B8 FC C4 4D 9F 8D E8 3F 89 D2 42 12 CF 58 7F BF 61 02 D8
MD5: D5 5F E7 FF 78 05 13 43 83 88 57 23 61 C3 12 A3
We also sent out these fingerprints out over Twitter as an extra method for you to verify them and that we really updated the certificate.

Note that this wilcard certificate is only for *.sixxs.net and sixxs.net itself. As wildcard certificates do not cover for instance www.ipv6.sixxs.net, we will keep on using the old CAcert certificates for other hostnames.

The SixXS website can be reached with this new certificate as:

• www.sixxs.net - Dual Stack IPv6 + IPv4
• ipv6.sixxs.net - IPv6 only
• ipv4.sixxs.net - IPv4 only

Other hosts, eg www.ipv6.sixxs.net use the CAcert certificate and thus need their SSL root certificate to be present on your host to verify properly.