Wednesday, May 4, 2011

Rock stars and session musicians

Something I've noticed since moving from the UK to the US is that potential employers are more likely to ask you for a link to your GitHub (or similar) account. In fact, some employers claim to value it more than a résumé. And who can blame them? A résumé says, "here are some things I would like you to believe I have done." A brimming GitHub account, or a well-maintained project site, says, "I get things done, and demonstrably so. I also like to share, and I'm probably more than a nine-to-five programmer."
But what does it say about a person if they don't? Not necessarily the opposite. In my case, programming is a passion. I've been doing it for fun since I was about five years old. I've been lucky that I could take something I enjoy and turn it into a career, but the day job and the programming I do at home are very different things. My day job is about deadlines, requirements, standardized platforms and change control. They're about the mechanics of delivering products as much as they are about the creativity of writing software. So it's nice to come home and spend some of my increasingly rare free time (I have a wife and a three-year-old) just experimenting and learning.
There's nothing really wrong with that, but there's always room for growth, and I see benefits to myself in 'putting myself out there'. I've recently embarked on a couple of longer-term personal projects. One of them is yielding a Werkzeug-based web app framework as an artifact, and I do intend to release that as open source eventually, even though for the moment it's easier for me to keep it in sync by developing it in the app's private repository.
All of this led me to conceive of the following analogy. Don't think about it too much, though, or it will fall apart.
Some programmers are like rock stars. They create a lot of content that they release with their own name attached to it, and it's a name people in the community know well. Their notability comes with exposure to direct criticism, and popular opinion of them can bias the reception of their work.
Other programmers are more like session musicians. You've probably never heard of them, but they've contributed professionally to many projects. You might even have unknowingly experienced their work as part of a larger product.

Monday, February 7, 2011

Understanding IP address exhaustion

On February 3rd, 2011, IANA announced that they had allocated the last of the IPv4 address spaces to the five regional internet registries. Since then, blogs and news sites have been reporting this and speculating about its implications. Unfortunately, there seems to be a lot of confusion and misunderstanding about how IP address allocation works and the terms that are used.

The management of this IP address space is delegated across a number of different organisations. At the top level is IANA (the Internet Assigned Numbers Authority), which is part of ICANN (the Internet Corporation for Assigned Names and Numbers). IANA's role it is to oversee global IP address allocation, and in the early days of the Internet, IANA would directly provide IP address to the organisations that would use them. Between 1993 and 2005, five Regional Internet Registries (RIRs) became responsible for allocations within continental-scale regions. These regions are:

* African Network Information Centre (AfriNIC) for Africa
* American Registry for Internet Numbers (ARIN) for the United States, Canada, and several parts of the Caribbean region
* Asia-Pacific Network Information Centre (APNIC) for Asia, Australia, New Zealand, and neighboring countries
* Latin America and Caribbean Network Information Centre (LACNIC) for Latin America and parts of the Caribbean region
* RIPE NCC for Europe, the Middle East, and Central Asia

In the APNIC and LACNIC regions, allocation is further delegated to National Internet Registries (NIRs) who will further delegate to Local Internet Registries (LIRs), who are ISPs or other large organisations who need control over their own routing. In the other regions, the RIRs directly delegate to LIRs. (My experience was with operating a LIR in the RIPE region.) At each level, the allocations are smaller. IANA allocates /8 blocks to RIRs (about 16 million addresses), whereas LIRs receive a default initial /19 allocation (8192 addressess).

Even after all these levels of allocation, the IP addresses are still not considered to be in use. Although an LIR can announce all of its *allocated* ranges, it is expected to formally *assign* parts of those ranges to its customers. The upshot of this is that despite Thursday's announcement, end-users will still be receiving assignments... but only for a few more months.

What happens then? Ultimately, we're going to have to move to IPv6, which, as well as having a 128-bit address space, provides a number of other benefits, such as auto-configuration and improved address mobility. Although IPv6 seems new, the first deployments were in 1999, and it has had extensive testing. For a typical end-user, the transition shouldn't be difficult, as all the major operating systems have good IPv6 support. More advanced users can start using IPv6 now, if they want. Even if your provider doesn't support it, you can use a free tunnel provider such as Hurricane Electric or SixXS. There are also transition mechanisms such as Toredo (which tunnels IPv6 in UDP in IPv4, so can be used through NAT gateways) and 6to4 (which tunnels IPv6 in IPv4, so requires a public IPv4 address). The problem lies with any ISPs who don't have a clear IPv6 deployment strategy. While your desktop computer got its IPv6 support through an OS upgrade, the high-speed routers that ISP networks run on need hardware support. Some ISPs are already offering IPv6 to their customers, and others are beginning trials, but some haven't announced any timeline. The one thing that is clear is that the coming months will see a mix of organisations that sail through the transition and those that find themselves in an 11th-hour panic.