Dec 072012
 
Spend 30 minutes with IPv6 every Friday!

Work with IPv6 continues. I do see changes in my customer base. In every meeting, regardless of the topic, I get a question about “that IPv6 stuff”. People are curious on what’s happening.
My recent answer has been ‘-It’s making huge progress. It’s gone from not being on the to-do list to “Yes, hmmm. We will have to do something about that, put a priority on it. That’s progress.When trying to change the world, one has to be observant of every little change, regardless of how small it is. My next comment usually is something along the lines of “Aren’t you using the Internet in your business? If so, why only stay partially connected? I thought Internet was important for you.” And that is becoming more and more true. Let’s check some news in the IPv6 news flow!

Akamai report 460 times increase in IPv6 requests!

Akamai publishes quarterly “State of the Internet” reports. The one for Q2 2012 reports a large spike in IPv6 requests – an over 460 times increase in traffic on the Akamai content-delivery network! They attribute a lot of the growth to the “World IPv6 Launch” event on June 6th.  (via CircleID)

4% of top web sites has IPv6 connectivity!

Dan Wing maintains a check list on the IPv6 connectivity of the top web sites on Alexa. In June 2011, about 1.3 % of the sites had IPv6 connectivity. One and a half year later, the number has grown to 4%. That’s a huge change, considering the large amount of traffic we’re talking about.

Romania is in the lead!

IPv6 deployment in Sweden according to Cisco 6LAB

According to the Cisco 6LAB Romania is in the lead in IPv6 deployment. The overall IPv6 deployment is 71%, compared with Sweden at 24%. In Romania 8% of the users have IPv6 connectivity, in Bhutan 7%, Japan 2% and the USA 2%.

The report behind the 6LAB points out the methodology used, data sources and gives a summary of where IPv6 is heading. The author of the report, Hugo Kaczmarek,  says “IPv6 migration of the last 10 years can be represented as a classic Mexican standoff” – everyone was waiting for someone else. The author points out how the World IPv6 Launch changed this landscape by focusing on getting content up and accessible over IPv6. After the launch, few people can say “there’s no content on IPv6″.

“Basically no one could see a benefit in being the first mover, and the risk was perceived too high. At the same time everyone understood that it was a move, the industry needed, to make sure the Internet could continue to grow, prosper, and innovate. If anything, this is the landscape the World IPv6 Launch (6th June 2012) event has changed forever.”

The author, like me, agrees that there is an attitude change happening in enterprises and use this graphic to show the change:

 

Summary: We’re making progress!

As I said earlier, my feeling is that we are making progress. Change takes time and you have to start with attitudes and knowledge, then move to implementation. Talk about IPv6 in every possible network-related discussion, from web site scripting to firewall design and network architecture. Include it by default in all new projects. Lab with it at home, in the office and while playing with that cool application you wrote in LUA. Ask for it when buying new products or services. All the figures for IPv6 points upwards, the Internet growth will clearly happen on IPv6. Make sure you are connected to all of Internet, not just the IPv4 side of it!

Well, that’s all for this week. I need to focus on adding IPv6 to my SIP survivability server and test dual stack, single stack and broken stack deployments (NAT).  Have a great IPv6 weekend!

/O

 Posted by at 10:11
Nov 162012
 
Spend 30 minutes with IPv6 every Friday!

I spent last week in Phoenix, Arizona. My eyeballs are very happy – one week of blue skies and a lot of good network labs in my SIP training class. In the beginning of the week I had a discussion about Happy Eyeballs – the way modern web browsers running in dual stack connects to the web server without bad affects on the user experience. The person I discussed with thought the problem was solved – he had not realized that this affects all application protocols – from SIP to Email, chat and p2p applications. Let’s discuss Happy Eyeballs and how to test it!

Happy Eyeballs – a quick introduction

When both a client and a server runs dual IP stacks, both IPv4 and IPv6, the client needs to find the best possible – and working – connection between the two computers. In the early days of IPv6, client computers set up automatically configured tunnels of various types, that usually was blocked in the firewall. The client believed it had a working IPv6 Internet connection and, following the standards, tried with IPv6 first. After failure, some clients failed and some retried with IPv4. The big problem was that the failure took time – between 15 and 30 seconds, depending on the protocol used. The user actually had a working connection path – over IPv4 – but running dual stacks caused delays and broken connection attempts. In total, not a good solution.

The Happy Eyeballs RFC from IETF suggests a change in procedure. The client now sets up connections over all possible network paths at the same time. The connection that succeeds first is the one used. No priority over any specific type of IP protocol, just get connected and make the user happy.

Making all protocols happier – testing, testing, testing

While this is was initially applied to HTTP, it affects all applications. A priority is applications where the user is waiting for a response, for some actions on the screen or in the headset – like SIP call setups, Email delivery to a mail server and of course game interaction. We’re going to take a look at wget and curl in this example, to show you the problem and how you can set up a test.

Start with setting up records in DNS

A requirement for testing happy eyeballs are that both client and server are dual stack. You need to set up one DNS name with two addresses, one for each family. In my example I’ve set up two DNS names – badipv6.test.ipv6friday.org and badipv4.test.ipv6friday.org

badipv6.test IN AAAA 2001:DB8::2042:3042
badipv6.test IN A 212.3.14.213
badipv4.test IN AAAA 2a02:920:212e::213
badipv4.test IN A 192.168.42.42

So what’s the trick with these? Well, the IPv6 address for the badipv6 entry is a documentation address, not routable anywhere. It simply does not work. The IPv4 address is the address for this site. For badipv4, the IPv6 address is the address for this site. The IPv4 address however, is an RFC1918 private IPv4 address, again an address that is  not routable on the Internet. A perfect setup for Happy Eyeballs!

Testing with wget

You can surely test this with any browser. If they are old enough, you will encounter a problem trying to access badipv6. The rule used to be that dual stack clients should try IPv6 first. In this case, it’s not going to work. An HTTP client that has no support for Happy Eyeballs will fail. Let’s test with wget, a popular Linux/Unix command line tool to fetch files with HTTP.


# wget badipv6.test.ipv6friday.org
--2012-11-15 18:06:53-- http://badipv6.test.ipv6friday.org/
Resolving badipv6.test.ipv6friday.org... 2001:db8::2042:3042, 212.3.14.213
Connecting to badipv6.test.ipv6friday.org|2001:db8::2042:3042|:80... failed: Operation timed out.
Connecting to badipv6.test.ipv6friday.org|212.3.14.213|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 226 [text/html]
Saving to: `index.html.1'

wget clearly has a happy eyeballs problem. You do not see the time it took for it to time out on the IPv6 address before it failed over to IPv4. Running wget to badipv4 was no fun, since wget starts with IPv6 and succeeds directly.

So let’s try another similar tool, curl v 7.24 by Daniel Stenberg, one of my friends. I’ve talked with Daniel many times about Happy Eyeballs, but curl still has the issue. It tries IPv6 and waits forever, then times out and fails over to IPv4.  (I guess that it may have something todo with me not being able to attend the Stockholm FOSS beer meetings…)


curl -v http://badipv6.test.ipv6friday.org
* About to connect() to badipv6.test.ipv6friday.org port 80 (#0)
* Trying 2001:db8::2042:3042...
* Operation timed out
* Trying 212.3.14.213...
* connected
* Connected to badipv6.test.ipv6friday.org (212.3.14.213) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.24.0 (amd64-portbld-freebsd8.2) libcurl/7.24.0 OpenSSL/0.9.8q zlib/1.2.3
> Host: badipv6.test.ipv6friday.org
> Accept: */*
>
< HTTP/1.1 200 OK

...

The good thing coming out of this test is that while both clients show the issue, both of them actually fail over to IPv4. Curl is also a library, used in many applications. One of them is the Asterisk Open Source PBX . In Asterisk CURL is frequently used in dialplan processing. A timeout on over ten seconds is not acceptable while setting up a call. If you use Curl in your application, you need to buy Daniel a beer or two so that we all get this fixed. Or fund his work so he can assign time to work on making your eyeballs more happy.

Test your own applications

Testing HTTP is low hanging fruit. The same problem applies to all TCP based protocols (and possibly UDP too). With a DNS setup like the one I used for the tests documented here you can run your own tests. I’ve done it with SIP clients and the results are not pretty. The TCP/IP community needs you, so do not forget to report back and tell others about your findings. Your favorite SSH client is affected, your FTP client as well as your e-mail software. We have a lot of work todo. The web browsers have worked with this issue for a long time, and have shared their implementation experience. I am working in the SIP Forum IPv6 working group trying to find out how we can proceed in fixing this – where are you going to start?

Have a great IPv6 week!

/Olle