News of 2015

permlink

SixXS wishes everybody a happy and fruitful 2015!

Indeed, it is 2015 already, so lets see if we will be really getting a functional Hoverboard this year as was predicted.

Of course, even more than last year, where IPv6 rose to 5% of the average Internet traffic, we expect traffic to rise even more with more and more native deployments.

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

permlink

Email providers around the world are becoming more and more strict with respect to checking the origins of email, that is where they are sourced from and if they pass through defined policy.

To make sure that email from SixXS is properly arriving in everybody's inbox we have taught our systems to send email through a centralized cluster which then signs the messages with DKIM for us. That cluster is then allowed to send email outbound to the recipient thus ensuring that SPF checks succeed.

We have additionally enabled a DMARC policy to give us a little bit of feedback on failures.

For the time being our DMARC policy will be 'none' and our DKIM signing policy is set to 'relaxed', but our SPF policy is set to strict (-all) thus only our cluster of hosts are able to send outbound email.

We hope that makes receiving hosts a bit more trusty in our emails and that we can avoid any phising going on out there. The Internet is really like the wild west in that respect.

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

permlink

During the run of 2015-04-10 (10th of April 2015) we will be performing various backend upgrades and updates, primarily also concerning the network of our backend hosts.

Due to this the dynamic portions of the SixXS website will become unreachable. This will primarily affect amongst others:

• SixXS Database
• TIC queries (and thus operation of AICCU)
• Signups, new Tunnel and subnet requests
• Accessibility to the User Home
• Statistic collection (latency and traffic)

The work will likely affect the site for a maximum of 8 hours, hopefully less. Indeed this will create a gap in the statistics, unfortunately there is little we can do about this, the collection system is not designed for HA as RRD does not provide a method an easy method for being updated on multiple hosts and synchronizing between them when the hosts rejoin the network.

Note that the PoPs themselves will remain operational, as they operate independently from the backend systems. Tunnels thus will remain operational when they have been configured. Indeed, restarting AICCU or another TIC client will fail when the TIC server is unavailable.

This will be only the second maintenance in over 10 years, we hope that is not too inconvienient.

related link
permlink

6 years ago it was not possible yet to get direct AAAA records for Wikipedia and Google. In 2009 we thus launched a DNS Cache service which enabled resolving of AAAA records for Wikipedia and various Google properties as these only allowed whitelisted resolvers to resolve these records. This allowed using Wikipedia and Google using IPv6 and allowed these companies to test how well IPv6 would work for them. Obviously it worked out all quite well as they have enabled AAAA for all resolvers since a few years. The IPv6 DNS whitelists are not used anymore(*) and every DNS resolver receives AAAA records when asking for them.

We thus have decided to stop providing the DNS Cache service as local resolvers will provide better latency and more accurate results with regard to DNS servers that have a variant of Geo-based DNS queries and answers. We suggest users to set up either a local DNS resolver or use their ISP provided one.

We'll peek on the resolvers to see who are still querying these DNS caches and notify these users per email that the service will be ending per 2015-06-06.

* = Google does have 'no-AAAA' list internally based on success rate of IPv6 connections, thus that might clarify why you might not see a AAAA record when trying to resolve through your local cache.

related link
permlink

After giving a bit more extra time for folks to swap over their resolvers to their ISP provided or local resolver, we have today shut down the DNS Cache service.

Note that our servers are thus rejecting UDP and TCP packets on port 53 by replying with a ICMPv6 Destination Port Unreachable. We are not sending any DNS response packets, providing fake answers or other nasty tricks. If a client is still trying to use these servers they should thus properly fail over to other configured servers.

May the AAAA be with you.

permlink

We started DNSSEC signing 7 years ago. Only a few of the ISPs providing the SixXS PoPs provide a DNSSEC delegation for their reverses path though. Thus requiring the need for a DLV setup to be able to verify the signatures.

ISC has recently announced that they intend to shut down their DLV service that we where using.

As overhead of DNSSEC signing is quite large (read: we served 4G of DNS data, most of that is DNSSEC signatures) in combination with low usage of actually signed zone, the time has come to stop signing DNS zones with DNSSEC on our servers.

We have thus stopped signing the zones and have removed the zones from dlv.isc.org Note that one can individually still register zones in DLV and one can also still configure DS records that we will publish.

related link
permlink

Sometimes we hear claims that SixXS does not support Free Speech when we reject a tunnel application towards a location where Free Speech is limited by their governments or organisations and the user indicates that they want to circumvent these restrictions.

We would like to clarify why we have to reject these kind of applications, doing so here will hopefully shed a light on the fact that we are not against Free Speech, but are attempting to protect the user.

An adversary who would like to limit Free Speech is likely to monitor internet connections. Users therefor use tunneling/VPN techniques to circumvent the monitoring of these networks. A SixXS tunnel is a point to point link from the user to the PoP. The addresses, both IPv4 and IPv6, of the PoP are publically known. The protocols used for tunneling are publically documented and known: proto-41 and AYIYA. Neither of these protocols encrypt the contents of the communication. Neither of these protocols cause any kind of hiding of data. On top of that Whois provides all the details about a user given a IPv6 address.

Any adversary network that wants to monitor thus only has to fill in our PoP IPs in a special list and they know that anything talking to those addresses are using a tunnel, which is a red light that that user is doing something special. Their next step is to simply de-encapsulate the traffic inside the tunnel and the adversary has full access to what the user is sending. Noting that all major monitoring systems understand these protocols.

SixXS thus cannot be used for circumventing for instance the Great Firewall as that firewall knows about proto-41 and AYIYA and just reads along. Indeed, AYIYA works perfectly fine through the GFW, but it does not hide in any way what you are doing.

Thus when a user specifically puts in their request reason that they want to circumvent their local government, we reject the request and point that user to the Tor Project. Approving the request would put the user in a situation where they might think they are avoiding the monitoring system and thus give a false sense of security.

Note that the goal of SixXS is IPv6 Deployment - getting IPv6 to the user. We unfortunately do not have the proper capabilities to provide circumvention. Other projects, like Tor Project have their full goal for solving anononimity on the Internet. Tor also has full time employees who are working towards this goal. As such, if you want anonimity, we heavily suggest using Tor.

While SixXS does not provide any method of circumvention, SixXS Staff have done extensive work on progressing Internet Anonimity.

Closest related to SixXS and IPv6, we have provided the core of IPv6 patches for Tor, these thus enabled IPv6 connections in Tor allowing people with IPv6 connectivity to reach the Tor network. Indeed, you can and are allowed to use Tor over SixXS provided IPv6 connectivity but keep in mind that an adversary who can see either the IPv4 or IPv6 traffic can recognize it as Tor in most cases. Also keep in mind that it is the responsibility of the tunnel owner to make sure that no abuse comes from their network, hence we advise to not run any exit nodes. Tor relays are absolutely fine though as these just transit traffic.

We have given talks at the Chaos Communication Congress discussing "How The Internet Sees You" (Slides | YouTube) which touches directly upon the core matter mentioned above: when you tunnel (proto-41/AYIYA) the monitoring system will flag you as doing something that other than "normal" people are doing and thus you stand out in a very big way thus causing the system to focus a closer look on what you are doing.

In a Tor related project we have written several new tools together with a group of other people:

• JumpBox (Code | Paper | Slides) which makes HTTP traffic look like normal browser traffic and solves the Parrot is Dead problem.
• StegoTorus (Website | Code | Paper). which is a camouflage proxy for Tor, tunneling Tor through ordinarily looking HTTP using steganography to hide the real traffic.
• Address Change Signaling (Paper | Code) an attempt to make it harder for a monitoring system to discover what is really running on a host.

Hopefully this clarifies our standing on Freedom of Speech and network neutrality in general: we would love to provide connectivity to everybody, but we cannot due to technical limitations that would put people in the spotlight and thus likely into jeopardy.

permlink

The 'Internet Protocol, Version 6 (IPv6) Specification' codified in RFC1883 is from the 1st of December 1995, which is now already 20 years ago. RFC1883 was the first formal specification of the 6th version of an Internet Protocol. This thus makes IPv6 20 years old and ready to drink as any other well aged whisky. With another milestone year around the corner: two-thousand-IPv6-teen we hopefully will be seeing mass IPv6 deployment at every ISP in the world.

If your ISP does not have IPv6 today, and does not have a plan to get native IPv6 to your doorstep in the next few months, we can only suggest to jump ship and find a new ISP as they have been slacking behind for a decade already where RIR address space has been available. Two full decades if you include the good old 6bone times where lots of people around the world where experimenting with IPv6 already.

To push IPv6 over the edge at ISPs who have not seen the light yet, we'll be making a harsh move: January 2016 will be Call-Your-ISP-for-IPv6 month. We are asking every person who does not have native IPv6 yet to call their ISP and demand IPv6.

To further this goal SixXS will stop accepting new account registrations, tunnel and subnet requests per X-mas (24th of December) 2015. We'll resume signups, tunnel and subnet requests again in the run of February 2016. This will give everybody who gets an IPv6 enabled toy over X-mas the time to call their ISP and ask where their native IPv6 is and when they will be getting it.

Of course, don't only call up the ISPs for native IPv6 connectivity, also call up the companies who produce your toys and whom do not support IPv6 yet.

Hopefully this will give a little extra incentive to the ISPs who have made no New Years plans yet, to put on that list, to finally think about IPv6. Two decades of planning should be enough warning time for them to realize that the time is ripe and IPv6 really turned into a young lady already and is not a kid anymore.

2016 will also be the year that SixXS will have existed and operating for 15 years. We'll have a done a long 16 years of operating IPv6 Tunnel Brokers for free and fun by then, including the predecessor IPv6 Tunnel Broker IPng.nl that started in the year 2000.

At one point though SixXS will want to close the doors as running the system is a very time consuming thing, and while we started this out in our late student years combining it with real work and family makes time very tight to provide this service for free for the 45k of active users. Hence, make your ISP support native IPv6, even if you have an account already and have been enjoying this service for a long time.

We'll be repeating the Call-Your-ISP-For-IPv6 actions through out 2016.

Hopefully you will be calling your ISPs enough that their callcenters will have IPv6 requests as the most common problem being called about.

Note that a call is a few moments of your time, but a huge burden on the ISP as it reflects badly in their statistics and that will be visible on the CEO level quickly, thus might actually make them finally do something about IPv6.

We wish everybody good luck in arranging native IPv6!

Please also support IPv6 For Refugees who donate 10 Swedish SEK for the large refugee catastrophe for every unique IPv6 address visiting their page.

permlink

Currently SixXS is not accepting signups, nor tunnel or subnet requests.

We are doing this action to ensure that instead of going the easy way of using our service for IPv6 connectivity, you instead Call your ISP.

20 years ago RFC1883, the RFC that formally defined IPv6, was published by the IETF. From 1996 till 2006 the 6bone existed and functioned as a testing ground for IPv6. Per 2006, which is now a decade ago, IPv6 has been available worldwide in production from a large variety of ISPs.

During the last decade, IPv4 address space has also run out at most of the RIRs and most of the large Internet properties have enabled IPv6 on their services.

We still see a large number of daily account signups, tunnel requests and subnet requests here at SixXS, which demonstrates that there are a number of ISPs who have not taken the time or effort to deploy any kind of IPv6 for their customers.

SixXS has been in existence since 2001-ish. And over the last 15 years we have been providing connectivity to people around the world.

Unfortunately it seems a large number of ISPs think that our service is a free pass for them to not deploy IPv6, as they direct their (paying) customers who want IPv6 to our service.

With IPv6 being 20 years old now, IPv4 addresses being out, we are stopping accepting signups and tunnel & subnet requests for the month of January 2016. During that time, we hope that you call your ISP and demand the IPv6 that you are supposed to have. We hope, that by people calling their ISPs, the number one support ticket will be "I want IPv6" and that these ISPs who have typically not moved a finger yet in the last two decades to deploy or even test IPv6, will be finally putting IPv6 on their roadmaps

We'll thus re-open signups during February 2016, but we note that we will be repeating this Call-Your-ISP-For-IPv6 action throughout 2016.