December 2007 Archives

ICANN's 2006-2007 annual report is now available. In it, Vint Cert, the outgoing Chair, makes this statement:

We are also anticipating the rapid run out of IPv4 address space and hence a strong need to introduce IPv6 into full operation. That this is a significant undertaking is an understatement. That it has to be undertaken by every operating element of the
public Internet is also understood. ICANN needs to convey to the Internet community persistently and persuasively that we all need to put the Internet into full IPv6 operation well before we run out of IPv4 addresses in 2010. (emphasis added)

I absolutely agree 100%.

The ICANN Strategic Plan (page 34 of the report) includes this objective:

Monitor the depletion of IPv4 address space and provide leadership towards IPv6 adoption. (emphasis added)

Well, ICANN could start providing leadership if they IPv6-enabled all of their public-facing servers. Their web site, mail servers and all but one of their authoritative nameservers are IPv4-only. I always find it laughable when large network policy bodies issue edicts about the urgency of IPv6 adoption, when they haven't deployed it themselves.

I thought it would be good to have a non-technical entry today.

This morning, I received an email from a friend. He's a very technical guy with a home network for sharing media between several Macs. Last night, he went poking around with netstat and noticed that he was using IPv6 to connect to his file server. He was curious about "these strange looking IPv6 addresses," which, it turned out, were link-local addresses that his machines had self-assigned. All of his machines are Macs, so they are using Bonjour to find their peers on his network.

So I explained what had happened:

What's happened is that your machines are on the same network and are using Bonjour-enabled services. OS X's network stack will use IPv6 in preference to IPv4. Since it can use IPv6 to talk to you AFP server, it did. No harm done.

Note that your Macs won't (and can't) use IPv6 to connect to anything off your home network, since they don't have publicly routable IPv6 addresses.

I also pointed out that it wasn't just his home machines that have IPv6 enabled. His work machines have it enabled too. But again, they just have link-local addresses, so they're not hurting anything.

Ultimately, he wanted to know, "for a home network, is there really any advantage to using IPV6 or should I just disable all of it? "

Excellent question! I wanted to share my response with the group, in the hope that others find it useful.

For the immediate future, there's no harm either way. It's not hurting anything to leave IPv6 enabled. In fact, one could argue that it's working exactly as it should: Until you went snooping around, you didn't even notice that you were using IPv6 :) Everything still just worked. Alternatively, if you disable IPv6, you won't break anything.

IPv6 link-local addresses are mainly used for "network housekeeping" on v6-enabled networks. Bonjour can also use them to find servers on the subnet. But it can also use IPv4.

It looks like the next version of Python will include an IPv6-safe convenience function to open a connection to a server: socket.create_connection(). You can see the gory details in the svn commit message.

This is A Good Thing. It wraps a rather verbose bit of code:


msg = "getaddrinfo returns an empty list"
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
    af, socktype, proto, canonname, sa = res
    sock = None
    try:
        sock = socket(af, socktype, proto)
        if timeout is not None:
            sock.settimeout(timeout)
        sock.connect(sa)
        return sock

    except error, msg:
        if sock is not None:
            sock.close()

raise error, msg


This code requests a list of all the addresses (both IPv4 and IPv6) for host using the socket.getaddrinfo() function. It then loops over that list, trying each address until it finds one that works. If none work, it raises an exception.

Python's socket.getaddrinfo() is quite handy. It's a Python wrapper around the C getaddrinfo(3) function, which is defined in RFC 3493: Basic Socket Interface Extensions for IPv6. I'll talk more about it in a future blog entry on how to write IPv6-clean programs (and make sure they still work with IPv4).

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.

Here's a random little tip: To check if your platform's Python interpreter was built with IPv6 support, run this program:


$ python
Python 2.4.4 (#1, Jan 10 2007, 01:25:01) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.has_ipv6
True
>>> ^D

Severity: RFE

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

The popular caching proxy, Squid will get IPv6 support in version 3.1. As of yesterday, the IPv6 patch has been merged into their CVS repository.

This is great news, since the IPv6 transition will need scalable dual-stacked proxy servers. It's been possible to setup such a proxy using Apache 2's mod_proxy, but Squid is a popular choice for caching servers. Here's hoping that a successful 3.1 release is soon :)

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?

Recently, I've been seeing a lot of articles online claiming that IPv6 will make networks more secure because it makes port scanning harder. One example is this blog entry from a Microsoft employee who works on MS' DHCPv6 server team. He claims:


The addresses generated by the DHCPv6 server are sparsely distributed over the available address space for that subnet. By randomly distributing the address over the large address range made available by a 64-bit IPv6 prefix, the Windows DHCP server makes it much harder to guess IPv6 network addresses.

The idea is that the sheer amount of time it would take to scan a 64-bit subnet (18,446,744,073,709,551,616 addresses) is simply beyond the scope of an attacker, even one using a very large botnet (presumably containing many multi-core machines using asychronous code).

I think this notion is false. The larger IPv6 address space doesn't buy you much additional security.

Any compotent network admin will be running an IDS. That should detect the port scans (and optionally block them if you have an IPS). Also, you can use network breakage devices, err, firewalls, to block incoming connections to prohibited ports. Further, if your attacker has access to your physical network, he doesn't have to scan the entire space. He can exploit a feature of IPv6 to get all the nodes on the subnet to announce their presence.

All IPv6 nodes are required to join a link-local multicast group. It's used for various "housekeeping" functions on the subnet. But it can be (ab)used by an attacker. If an attacker pings FF02::1 (the link-local multicast group), every other node on the link will respond via their link-local address. From there, it's not too hard to guess their public, routable addresses, especially if stateless autoconfiguration is enabled.

I mentioned in an earlier entry that I've configured my workstation (OS X 10.4.11) only to use IPv6 for DNS queries. Today, I found something that this broke: Kerberized CIFS. So far, I've only noticed this on OS X 10.4. It does not happen on OS X 10.5. I haven't had time to test any other platforms.

A few months ago I gave a talk at the SOS Security Day on using Kerberos for various network services. One of the things I discussed was kerberized CIFS. I had verified that this worked on OS X using the u: drive. This was before my IPv6-only DNS change. Today, a colleague asked me to reverify my findings, since he was having issues. I was unable to obtain a service ticket in the u: drive's Kerberos realm. After some grepping through the Kerberos source, I've found the source of the problem.

Kerberos can discover configuration data for foreign realms using DNS SRV records. The u: drive is in its own Kerberos realm, so my client tried to look up the KDC hostnames using a SRV record query. The MIT Kerberos libraries included with OS X 10.4 can only use IPv4 to perform the query. To resolve the issue, you have to add an IPv4 DNS server to my resolver configuration, and I had to list it first (which means that most DNS traffic will only go over IPv4). Alternatively, you can explicitely configure your krb5.conf file with the u: drive's realm, which is what I did.

The issue appears to be fixed in newer versions of MIT Kerberos and in Leopard.

I just saw this announcement, even though it's a few months old. It claims that

...from January 1st, of 2011, NIC Mexico will not be able to allocate anymore IPv4 addresses and will only assign IP addresses in version 6 of the Internet Protocol (IPv6).

This is just wrong. I have to hope that the English translation of this press release is inaccurate.

It is currently estimated that the IANA pool of IPv4 addresses will be exhaused in late 2010. On that day, it will not be the case that every publicly routable IPv4 address will be allocated. IANA allocates IPv4 address prefixes to the Regional Internet Registrars (RIRs). Mexico belongs to the Latin American and Caribbean NIC (LACNIC). When the IANA pool is depleted, LACNIC will be unable to go to IANA to satisfy IPv4 requests from its members. It will have to make do with whatever addresses it has in its own pool. RIRs are expected to maintain sufficient size in their address pools to satisify 18 months of address requests.

As of this writing, Geoff Huston at APNIC estimates that IANA's pool will run out on September 27, 2010, and that the RIRs' pools will be depleted about a year after that. So, NIC Mexico's assertion that as of January 1, 2011, it will be unable to satisfy IPv4 requests seems silly provided that LACNIC is maintaining sufficient free addresses in its pool. NIC Mexico's announcement is especially ironic given that their web and mail servers are only accessible over IPv4 (so their new IPv6-only customers will be unable to contact them). Also all of the authoriative nameservers for the .mx domain are IPv4-only. It seems that NIC Mexico need to get its own house in order before issuing grandiose proclamations.

The IPv6 transition plan calls for nodes to be dual-stacked. That is, they have to have both IPv4 and IPv6 addresses. Once a sufficient number of hosts have enabled IPv6, only then can we think about turning off IPv4. It's shortsighted for NIC Mexico to announce that they won't allocate IPv4 after 1/1/2011. All they will accomplish is creating a heap of pain for telecom providers in Mexico by prematurely cutting them off from the IPv4 Internet.

Most customers don't care about IPv6. It's the job of the RIRs to make them care. Customers want IPv4. They have to go the RIRs to get v4 addresses. If the RIRs try to cut them off, frankly, the RIRs will have given up their power (since they will no longer give customers what they want). Customers will likely look elsewhere for the v4 addresses, such as buying already allocated v4 addresses from other entities in LACNIC's region, or by deploying complex multi-level NATs.

This approach seems good intentioned, but too heavy handed. It's best to work with your customers, not beat them with a large stick and expect them to say "thank you."

OpenSolaris now supports using class E addresses. This work is based on an internet draft calling for 240/8 - 255/8 to be made available for unicast use. This is being done to help push out the exhaustion of the IPv4 address space, which is estimated to occur in late 2010.

While efforts to coax some more life out of IPv4 are perhaps commendable, I have to question this change by Sun. The IETF hasn't ratified this proposal. In fact, the proposal is in its first draft. But more fundamentally, I'm not sure I see the point of these efforts. Take a look at this graph:

Since 2000, IANA has allocated an average of ten prefixes annually. Adding sixteen class A networks into the free pool will only add 1-2 years (at most) of life to the IANA pool. Of course, it takes a few years for an address to filter down from IANA to the RIRs, LIRs and eventually be deployed. I'd roughly guess that this would add maybe five years of extra time to IPv4. Further, making class E addresses usable will require significant device upgrades, as many vendors prevent their use.

This proposal seems like a short-term band-aid. IPv6 offers a real long-term solution to IPv4 address space exhaustion.