Tag Archives: ipv6

How To Read IPv6 Addresses

A common complaint about IPv6 is that addresses are “hard to read”. If you’ve been in the networking world any length of time IPv4’s dotted quad is most likely seared into your brain and clumps of hexadecimal digits of varying lengths can can be hard to wrap your head around. However, those clumps can provide useful information.

Below I’ll go over some of the address types I’ve seen and show you what information they provide. Continue reading

Troubleshooting A Slow Web Site

A couple of weeks ago we had a strange problem in the CACE Technologies World Domination Secret Lair. Loris was having trouble loading the Wireshark blog. It was working fine on my machine so I checked some of the other machines in the office. I found the same problem on one of the development machines. Loading the page in Firebug showed that the object requests were stalling out every 20 seconds or so:
firebug-slow-blog
I fired up Wireshark and captured the browser attempting to connect to the blog:
ipv6 failure
The problem was immediately obvious. The browser attempted to connect to the blog’s IPv6 address (2607:f0d0:2001:e:1::1), timed out, and connected to the blog’s IPv4 address (67.228.110.126).

As it turns out Loris and I ran some IPv6 tests a long time ago and we added unique local addresses to our machines (mine was fd00:cace::4) . Since each machine had an IPv6 address the TCP stack assumed that there was general IPv6 connectivity. However, our ISP is steadfastly ignoring IPv6 so end-to-end connectivity wasn’t there. After timing out the connection fell back to IPv4 and proceeded normally.

This sort of thing will likely crop up more and more often as we transition to IPv6. If either IPv4 or IPv6 connectivity fails, your applications will still have connectivity so the failure may not be immediately obvious. In this case Firefox stalled out but still managed to connect. If it used a connect-by-name socket API the failure wouldn’t have been evident at all.

Debugging SSL Servers Over IPv6

An old-school method of debugging TCP-based services is to use telnet:

$ telnet www.wireshark.org 80
Trying 67.228.110.120...
Connected to www.wireshark.org.
Escape character is '^]'.
HEAD / HTTP/1.0
Host: www.wireshark.org

HTTP/1.1 200 OK
Date: Fri, 16 Oct 2009 19:31:47 GMT
Server: Apache
Accept-Ranges: bytes
Cache-Control: max-age=3600
Vary: Accept-Encoding
X-Slogan: Be good. You never know who's running Wireshark nearby.
Content-Length: 9628
Connection: close
Content-Type: text/html

Connection closed by foreign host.

It’s like giving your web server a big ol’ hug.

Most telnet clients do something very clever here. If you connect to a port other than 23 (or whatever getservbyname returns when you feed it “telnet”) they will disable telnet protocol negotiation and switch to line mode. This gives you a raw, line-based connection which is just the thing you need to interact with an HTTP, POP, IMAP, FTP, or NNTP server.

Adding SSL and IPv6 to the mix complicates things. I’m in the process of making Wireshark’s public-facing services available over IPv6. It would be helpful to be able to test connectivity to each service before adding its corresponding AAAA record. Standard telnet clients support 6, but not SSL. OpenSSL’s s_client command speaks SSL, but not over IPv6 (not on my systems, at least):

$ openssl s_client -connect '[2607:f0d0:2001:e:1::123]:443'
getservbyname failure for f0d0:2001:e:1::123]:443
$ openssl s_client -connect ipv6.wireshark.org:443
gethostbyname failure
connect:errno=110

Luckily Fyodor released Nmap 5 a while back. Nmap 5 includes ncat, which lets you connect over SSL+IPv6. It is now my new favorite service-poking utility.

$ ncat -6 --ssl -v 2607:f0d0:2001:e:1::123 443
Ncat version 5.00 ( http://nmap.org/ncat )
SSL connection to 2607:f0d0:2001:e:1::123:443. bugs.wireshark.org
SHA-1 fingerprint: F6BA 2EE9 DEEF 74D3 B4B0 86D7 F5DB 6237 FF7F 896A
HEAD /bugzilla/ HTTP/1.0
Host: bugs.wireshark.org

HTTP/1.1 200 OK
Date: Fri, 16 Oct 2009 20:26:23 GMT
Server: Apache
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=UTF-8

On many Linux distributions you can also use telnet-ssl:

telnet-ssl -z ssl 2607:f0d0:2001:e:1::123 443

IPv4 Exhaustion FAQ

Q: What does IPv4 exhaustion mean? Can’t you give IPv4 some Red Bull?

A: As everyone knows, the Internet was constructed by Theodore Roosevelt in 1895 using an old-growth forest and a thousand buffalo hides. He created a giant “pool” to hold all of the Internet’s numbers. While quite large for its time, the pool is much too small to handle the demands of today’s Internet.

Q: When will the pool run out?

A: In about eight and a half minutes.

Q: What will happen then?

A: The entire Internet will grind to a halt. It will shudder comically as it does so.

Q: But how will I get to Twitter? I gotta have my tweets.

A: In recognition of its role as the most important web site ever, the final IP address will be reserved for Twitter. In order to get there you will have to defeat an opponent in a cage match. You will get to choose between a crowd shouting “Two packets enter! One packet leaves!” or the Star Trek fight theme.

Q: Can’t I have something cool like Eye of the Tiger or that one Van Halen song that sounds like a motivational poster?

A: No. Not nerdy enough.

Q: I don’t want to fight a nerd in a cage. Is there another way to get my tweets?

A: No. Gotta battle a nerd.

Q: Really?

A: Well…

Q: Well, what?

A: You could use IPv6.

Q: What’s IPv6?

A: It’s a newer, better Internet created by Matthew Broderick’s character in War Games in 1983. Its number pool is huge. The addresses should last for dozens of months at the very least.

Q: How do I use IPv6?

A: You have to have a modern computer. You also have to have an ISP that supports IPv6 or create a tunnel.

Q: OK. Tunnel’s all ready to go. Can I have my tweets now?

A: No.

Q: Why not?

A: Twitter doesn’t use IPv6.

Using Shame and Embarrassment to Promote IPv6

In a previous post I proposed the terms “indoor plumbing” for native IPv6 access and “outdoor plumbing” for tunneled IPv6. I think terminology like this is important. It’s short, clear, and implies an easy-to-visualize hierarchy where anything less than native routing involves uncomfortable exposure to the elements and woodland creatures.

Which leads us to those poor souls with IPv4-only networks.

“Y-you mean to say that you don’t have any modern plumbing at all? (snork) BWAHAHAHAHAHA!”

We could use something similar for unsecured wireless connections.

Does IPv6 Adoption Depend on Akamai?

The ongoing effort to switch the entire planet over to IPv6 has a chicken-and-egg problem: there is little incentive to deploy it if no one else is using it. This is expected to change as IPv4 addresses become more scarce, but for the time being uptake is dismal (in the U.S. at least).

One easy way to measure IPv6 adoption is to see how many of Alexa’s top sites have AAAA records. Hurricane Electric and Lars Eggert do a good job of this. Following in their footsteps my own version of this data is shown below:

IPv6 Adoption - Alexa top 1000

IPv6 Adoption - Alexa top 1000

It shows IPv6 adoption in Alexa’s top 1000 sites along with the number of sites using Akamai. The number of IPv6 sites is pretty small but the number of “testing” sites is encouraging. See the notes below for a detailed explanation and breakdown.

Who is Akamai? They’re a giant content and application delivery provider. Continue reading

Wireshark.org and IPv6 plumbing

Wireshark has supported IPv6 since dirt was new. Unfortunately, the wireshark.org web site has only been available over IPv4. Until now, that is. If you are IPv6-enabled, you can reach the Wireshark web site at http://ipv6.wireshark.org. Nota bene:

  • The address above is only available over IPv6.
  • The main address for the site (http://www.wireshark.org) is still IPv4-only. We’ll add an AAAA record after a suitable evaluation period.
  • Other Wireshark sites (such as the bug tracker, wiki, and buildbot) are still IPv4-only for the time being.

In order to encourage the adoption of IPv6 I think the phrases “indoor plumbing” and “outdoor plumbing” should be used to refer to native and tunneled IPv6, respectively. Once you point out that an ISP has outdoor plumbing, they’ll want to add native IPv6 support out of shame.

Examples:

  1. Wireshark.org is hosted at SoftLayer. They have indoor IPv6 plumbing.
  2. Wave Broadband is so behind the times! I’m stuck with outdoor IPv6 plumbing at home!