Recently in bugs Category

This week in IPv6

| | Comments (0) | TrackBacks (0)

It's been a busy week for IPv6.

On Tuesday, the Squid web cache announced a beta of version 3.1, the first with IPv6 support. For those of you using Squid 2.x, there are plans to backport this code to release Squid 2 (the work will be spread between 2.8 and 2.9). This has been a long time coming — the code was merged almost a year ago. Given the dearth of IPv6 deployment, dual-stacked web proxies will probably be important during the IPv6 migration.

On Wednesday, UCLA IPv6-enabled its web site:


$ dig -t AAAA www.ucla.edu.

; <<>> DiG 9.4.2-P2 <<>> -t AAAA www.ucla.edu.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41596
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; QUESTION SECTION:
;www.ucla.edu. IN AAAA

;; ANSWER SECTION:
www.ucla.edu. 272 IN AAAA 2607:f010:3fe:101:101d:9ff:fe32:a7d1

;; AUTHORITY SECTION:
www.ucla.edu. 21572 IN NS dns3.ucla.edu.
www.ucla.edu. 21572 IN NS dns1.ucla.edu.
www.ucla.edu. 21572 IN NS dns2.ucla.edu.

;; ADDITIONAL SECTION:
dns1.ucla.edu. 21572 IN A 164.67.128.1

;; Query time: 11 msec
;; SERVER: 2610:8:6800:1::4#53(2610:8:6800:1::4)
;; WHEN: Fri Nov 7 14:19:28 2008
;; MSG SIZE rcvd: 131

As far as I know, UCLA is the first university in Internet2 to take this step. Congratulations!

On Thursday, there were several code commits to FreeBSD to remove IPv4 dependencies. The goal is to let the kernel be compiled without IPv4 support (one can only dream of such a day).

Also, RIPE (the Regional Internet Registry for Europe, Middle East and parts of Asia) published the slides from its meeting last month in Dubai. These were several excellent talks. Several European Internet Exchange Points showed growth in the number of IPv6-enabled customers.

Etisalat, a large Middle East telco, discussed their IPv6 deployment, which has been underway for most of the decade. They're motivated for the usual reasons: The significant increase in Internet-attached devices is exceeding NAT's usefullness. I found it interesting that they've required IPv6 support in new equipment purchases since 2001! I'm really hoping that Penn State adopts a similar policy soon.

Google presented two talks on its on-going IPv6 trial. As a refresher, Google doesn't see NAT as a long-term solution to IPv4 address depletion. In fact, they claim that excessive NAT will have significant negative impact on common web apps. So they've run an IPv6 pilot since March. So far, the results are very encouraging: Only 0.09% of users have broken IPv6 connectivity.

I'm glad to see that Google (among others) is actually gathering empirical data on IPv6 usage, since there is a lot of FUD about there that IPv6 will cause all sorts of breakage. To quote Google, "It's not that broken... don't believe the FUD."

Having said that, things are not perfect. IPv6 routing is often sub-optimal (to be polite). Gert Doering presented on the state of the IPv6 routing table, as asked "Why does traffic from Germany to Germany get routed through the US and Hong Kong? He showed an example of a user in Munich accessing a server in Frankfurt. The traffic went across the Atlantic to Washington, DC, across the continental US to Chicago, then Seattle, then across the Pacific to Hong Kong, then finally back to Germany. This has got to stop.

Google also sees these sort of problems. They had an example of traffic from Virginia to Virginia being routed through Amsterdam. All of this adds significant latency to IPv6, making users disinclined to use it. Fortunately, we know how to fix the problem: We need to start filtering IPv6 routes. We've done this for IPv4 for a while, and it's time to do the same for v6.

So that's the week in IPv6. There was a lot more covered at RIPE-57. I'll blog about that later.

Severity: Normal

Today's bug - GMime doesn't parse URLs with literal IPv6 addresses. This has been reported to them as bug 515088.

GMime is a popular library for handling MIME. Penn State's WebMail system uses it. It has a very useful module that converts plaintext email containing URLs into HTML. WebMail uses this capability. Unfortunately, it doesn't support URLs with IPv6 addresses, such as http://[2610:8:6800:1::7]/. This is a valid URL, per RFC 2732.

From what I hear, the GMime developers are very responsive to bug reports. I look forward to this being fixed. It'll be one small step to making WebMail IPv6-capable. :)
I've been looking into what it would take to get several of our applications IPv6-enabled. In some cases, it's trivial. In others, it's going to be hell. This post is about how several programming languages have added IPv6 support to their standard libraries. Well, it's not really a post. It's more of a rant. Because I'm angry. I'm angry that two of the most popular languages appear to have put no forethought into future-proofing their networking libraries.

PHP and Perl are excellent examples of how not to add IPv6 support to a library. The status of IPv6 in both systems is an utter mess that will take years to fix.

We have many apps written in PHP and Perl, which we will eventually need to IPv6-enable. Given the abysmal state of IPv6 in these languages, I'm not optimistic about success. Critically, it not possible to write applications in PHP or Perl that use a single API and will work on IPv4-only, IPv6-only and IPv4/IPv6 dual-stacked hosts. The inability to do this is dooming.

Non-programmers can skip to the last paragraph. What follows is techy.

Let's look at PHP. It got IPv6 support in version 5, but its gethostbyname() function still doesn't support IPv6. Of course, the documentation doesn't mention this fact. Instead, users should use dns_get_record(). (As an aside, why does dns_get_record() still support A6 records, which were deprecated years ago?). Alternatively, developers may use PEAR's Net_DNS class to resolve names. It appears as if there are cases where Net_DNS_Resolver::query() can fail to use IPv6 to connect to a DNS server, however (if using UDP and the "enhanced sockets library").

Then there are the IP address utility libraries: Net_IPv4 and Net_IPv6. First question: Why are there two of them? Why is there not a single network address library that can handle both formats? But it gets worse: The two libraries have different APIs. There is considerable functional overlap between them -- there are functions to apply a netmask to an address, parse CIDR-formatted addresses, etc -- but the function prototypes look nothing alike. For example, some of Net_IPv4::parseAddress()'s abilities are duplicated in Net_IPv6::getNetmask() and Net_IPv6::removeNetmaskSpec(). Both Net_IPv4 and Net_IPv6 have functions to verify if a string is a valid address, but they have different names: Net_IPv4::validateIP() vs Net_IPv6::checkIPv6(). There are other examples of this sort of mismatch.

I'll only mention briefly that there are two other modules for validating IP(v4) addresses: Net_CheckIP and Net_CheckIP2. Both of them only handle IPv4 and have different function names than the equivalent functions in  Net_IPv4 and Net_IPv6. This only serves to increase programmer confusion and encourage the development of non-IPv6-capable code.

And that's just the low-level code. There are still the higher-level libraries for dealing with IMAP, SMTP, HTTP, etc. I haven't begun an audit of PEAR's Networking library to check for IPv4-only code. I'm too afraid.

Perl isn't any better. For reasons that escape me, Perl decided to fork its network libraries into IPv4-only and IPv6 halves. Specifically, there are Socket (and it's object-oriented cousin, IO::Socket::INET) and Socket6 (and IO::Socket::INET6). Of course this means that developers have to change their code to get IPv6 support. Almost no OSes bundle Socket6 or IO::Socket::INET6, so developers are loathe to make such changes. (Kudos to Mac OS X 10.5 and Ubuntu 7.10 for supporting them).

Because the modules are separate, you have to write a bunch of ugly code. When your code starts, you check if you have one of the IPv6 socket modules installed. If so, set a flag. Then every single time you need to talk to the network, you check this flag and branch, either to Socket6 or Socket. This is a) ugly b) inefficient c) unlikely to be adopted by virtually all programmers d) all of the above. Check the source to the Net::DNS module for an example. I am not looking forward to submitting patches that do this. But someone is going to have to.

I contrast this to Java, Python and C which have sane, clean, standardized APIs that support both IPv4 and IPv6. In Java, it's unlikely that developers will have to change code. In Python, the changes are usually two or three lines. In C, it's slightly more lines than that, but generally not much more. I'll elaborate more on these languages in a later post. Readers at Penn State may want to look at my IPv6 programming notes in the ITS Wiki (which is IPv6-enabled).

When a user posts a comment to a MovableType 4 blog, MT4 logs the user's IP address. However, the relevant column in MT's database is only big enough to store an IPv4 address. Here's the relevant code from lib/MT/Comment.pm:


__PACKAGE__->install_properties({
column_defs => {
...
'ip' => 'string(16)',
...
},

PSU is using MovableType 4 for its blogging pilot, so I suppose I should submit a patch to fix this.

As an aside, it's disappointing that MovableType is storing the address as a string. I suppose this was done for portability reasons, but it means that MT can't take advantage of databases with intelligent IP address datatypes, like PostgreSQL. For almost a decade, PostgreSQL has had the inet and cidr datatypes, which are specifically designed for storing IP addresses. These datatypes have supported IPv6 since release 7.4 in late 2003.

I had to update a Python script early this morning. Being the anal-retentive perfectionist that I am, I took this an an excuse to an an informal audit of the Python networking library for IPv6-support. I was pleasantly surprised: Most of their networking library is v6-capable. Specifically, the libraries for sockets, http, smtp, xmlrpc, ftp, telnet, pop, and url parsing support IPv6. My findings are in the ITS Wiki.

A few libraries didn't fare so well. I filed bug 1655: imaplib is not IPv6-capable. I still need to file bugs on nntplib and SMTPServer.

I also filed another Mac OS X bug, 5653899 openssl s_client/s_server are not IPv6-capable.

Severity: RFE

The NFS implementation on OS X isn't IPv6-capable. This has been reported to Apple as bug 3502191.

Today, the IETF approved RFC 5095: Deprecation of Type 0 Routing Headers in IPv6. Every major OS has already disabled type 0 headers, but this makes the practice "official."

Severity: Minor


SubEthaEdit is a great text editor for OS X. I use it regularly. One of its most useful features is collaborative editing of a document. It can do this using Bonjour (née ZeroConf) networking to discover collaborators on the subnet. It can also work over a WAN. SubEthaEdit has supported IPv6 since 2004.

SubEthaEdit has its own URL syntax for identifying a document using the see URI scheme (which doesn't seem to be registered with IANA). Here is an example of a SubEthaEdit URL: see://bakunin.et-test.psu.edu/Untitled.txt?documentID=77E29585-B15C-40CF-83D5-6BD3479F5548

A user can generate one of these URLs by selecting the File -> Copy Document URL menu item and sending the link to a colleague. Herein lies today's IPv6 bug: On a dual-stacked host, SubEthaEdit embeds the host's IPv6 address in the URL. For example, here's a link from my desktop:

see://[2610:8:6800:1::408]/Untitled.txt?documentID=BE3C9836-C886-4DCD-8EB1-2AD1DC901E35

(notice the embedded IPv6 address, using RFC 2732 syntax).

My desktop, bakunin.et-test.psu.edu, is dual-stacked, and SubEthaEdit is listening on both IPv4 and IPv6. So it's a bug to only include the IPv6 address in the URL. Ideally, SubEthaEdit could check if all of the IPs on which it is listening resolve to the same hostname, and if so, use the hostname in the URL. But this likely would not be the case for addresses obtained via DHCP, and it most certainly is not the case for auto-configured IPv6 addresses. So, it's not an easy fix for the SubEthaEdit developers. Short of emitting multiple URLs (one for each address on the host), I'm not sure of how to fix it.

I've confirmed that static IPv6 addressing is broken in Leopard (at least via the GUI; it works fine from Terminal). I've filed this as bug 5643493 with Apple.

I think I've encountered a bug in Mac OS X 10.5's IPv6 configuration tools. If I try to configure a static IPv6 address in System Preferences, I don't actually get an IPv6 address. Here's my networking configuration:

When I run ifconfig(8), I don't have an inet6 entry:

$ ifconfig en0 | grep inet
inet 172.28.73.53 netmask 0xffffff80 broadcast 172.28.73.127

However, if I configure it from the command line, it works fine:

$ sudo ifconfig en0 inet6 2610:8:6800:1::40a/64
$ sudo route add -inet6 -prefixlen 64 default 2610:8:6800:1::1
add net default gateway 2610:8:6800:1::1
$ ifconfig en0 | grep inet
inet 172.28.73.53 netmask 0xffffff80 broadcast 172.28.73.127
inet6 fe80::216:cbff:feaa:879d%en0 prefixlen 64 scopeid 0x4
inet6 2610:8:6800:1::40a prefixlen 64

If I select autoconfiguration in System Prefs, I get an IPv6 address.

I'm going to check this on another machine on my home network before I file a bug with Apple. Has anyone else seen this?