The Internet is quietly being replumbed. That shouldn't surprise anyone involved with it; the Internet is always being replumbed. But you might be more surprised to learn that the next few years will bring an unusual burst of changes in that plumbing, some with great potential consequences for anyone who relies on the Net.

By "plumbing," I of course refer to the protocols and software that make the core features of the Internet work. These have been evolving steadily since 1969, but I don't think any period since the early 1980s has seen as many changes as we'll see over the next few years.

Like anything new, these changes will bring both threats and opportunities - but in this case, probably more threats than opportunities. Each critical part of your organization's infrastructure is potentially at risk from any fundamental change, and there will be several such changes in succession.

The Next Big Things
DNSSEC
For years, experts have warned that the Domain Name System, one of the most important subsystems on the Internet, is at severe risk from malicious actors. All sorts of schemes are possible if you can hijack someone else's domain name, and there are many ways to accomplish that hijacking. DNSSEC makes domain hijacking much, much harder, and therefore makes it more reasonable to trust the identities of Internet sites. It is the foundation for a more trusted net.

After years of work, a milestone was reached in 2010 when the root domain was signed with DNSSEC. Over the next few years, more and more sites will try to protect their identities and reputations with DNSSEC. The potential for breaking older or unusual DNS implementations can't be ignored, but any organization that has a lot invested in its domain name should consider using DNSSEC to protect it from hijacking and to reassure end users.

IPv6
The TCP/IP protocols were designed to facilitate what almost everyone thought was an absurdly big network - over 4 billion computers. Less than 30 years later, we all know (as I said in 1983, mostly to dismissive laughter) that the 4 billion addresses enabled by IPv4 are simply not enough. To keep the Net from fragmenting, to facilitate universal communication, and to avoid having the Net's growth stop dead in its tracks, it is essential that the world convert to IPv6.

Adoption of IPv6 has been slow, but there's a good reason to expect that to change: halfway through 2011, the supply of IPv4 addresses will simply run out. There are all sorts of half-measures and hacks that can postpone things a bit further, but by now it's clear that the future of the Internet requires IPv6. Despite the many person-centuries of work that have gone into IPv6, the transition is highly unlikely to be smooth and painless for everyone.

International Email Addresses
For as long as there has been Internet email, addresses have been limited to the ASCII character set. Spanish speakers can't use the letter "ñ" even if it's part of their name, and Germans similarly have to do without their "ö." They've been remarkably patient with what is, from their perspective, a gross inadequacy in the email standards. But the people who have it worst are Asians, as their characters are forbidden in traditional email addresses. What the world wants are email addresses like these:

After many years of wishing, arguing and working, the IETF is closing in on a solution. Internationalized domain names (the right-hand side of the email address) have been a reality for a little while now, and the IETF has been tackling the final bit, the left hand side. This turns out to be much, much, much harder than it sounds, because of the problem of backward-compatibility with the old standards and all the old mailers in the world.

The solution is going to be ugly, but functional. New encodings map ugly strings like "xn-bcher-kva.ch" onto desired internationalized forms such as "Bücher.ch." Ideally, users will never see the ugly forms, which are designed to be backwards-compatible, but inevitably they sometimes will. Worse still, it may be impossible for a user of older software to reply to email from someone with an internationalized address.

The bottom line: we'll be going through a period during which email will probably not be quite as universal, or as stable, as we're accustomed to it being. Anyone with responsibility for software that processes email addresses will need to make sure that their software doesn't do horrible things when these new forms of addresses are encountered.

DKIM
The fight against spam will never end, because the miracle of Moore's Law - the same miracle that gives us ever smaller and more powerful computing devices - operates in favor of the spammers. Every time we get twice as good at detecting spam, spammers are able to generate twice as much spam for the same price, which means that the good guys are running on a treadmill, needing to work continuously just to avoid falling behind.

One manifestation of that hard work is the DKIM standard, which stands for "Domain Keys Identified Mail." This specifies a procedure by which organizations can publish cryptographic keys and sign all its outgoing mail, thus making it somewhat easier to be sure where some messages really originate. It's far from a cure-all, but it has the potential - particularly when paired with as-yet-undefined reputation systems - to make it easier to detect spam with forged sender information, the issue at the heart of the "phishing" problem.

DKIM has been in development for several years now, and is progressing well through the standards process. It should be mostly invisible to end users, but will keep mail system administrators busy for a while. As they learn to configure outgoing mail for signatures and to check incoming mail for signatures, there is a strong potential for destabilizing the email environment in general. The most likely issue will be mail that just doesn't reach its intended recipient. That's a much higher risk during the period that DKIM - or really, any other anti-spam standards and technologies - are being newly deployed.

Reputation Services
High on nearly everyone's list, in the wake of technologies such as DKIM, are reputation services - trusted parties that can tell you if a message is signed as being from Joe.com, whether or not Joe.com is known for sending spam or other bad things over the Internet.

Although there are no standards for reputation services yet - and although they are undeniably needed - we can already see the risks and benefits by looking at the non-standardized reputation services in use today, notably blacklists of email senders. Although these are incredibly useful, there is a never-ending stream of problems with organizations that get added to such lists inappropriately, and the administrative difficulties of getting them removed promptly.

Similar considerations will surely apply to the standardized reputation services of the future - no such service can be any better than the support organization that deals with exceptions and problems. Any progress with reputation standards should be expected to be accompanied by transitional pains as the reputation service bureaus mature and develop good or bad reputations themselves.

What Can Customers Do?
Make no mistake, the coming improvements to the Internet's plumbing are a very good thing. But the implementation of each of them brings with it the potential for destabilizing various aspects of the Internet infrastructure, despite the heroic efforts of the IETF to minimize that risk.

Vendors can increase or reduce the risk through their quality of implementation. What can customers do?

Paradoxically, the answer is to do more by doing less. The biggest risks are inevitably found in the least professionally administered software and servers. The big cloud providers with the staff of crack programmers and administrators are at the least risk, because they understand the risks well enough to take steps far in advance. But that specialized application that your predecessor commissioned 10 years ago, and is now running more or less autonomously on an ancient server in your headquarters, could represent a huge risk.

Basically, the risk is highest where the least attention is being paid. The best thing that most organizations can do, in preparation for the coming instabilities, is to use fear of the unknown as an excuse to clean house a bit:

• Decommission old applications that aren't being maintained
• Outsource anything you can plausibly outsource to a bigger IT shop
• Allocate a few programming resources to pay attention to the ones you can't decommission or outsource

Of course, it can't hurt to ask your cloud provider or outsourcer what they're doing to prepare for the coming changes, but if they act surprised by any of them, it may be time to consider a new provider.

Ideally, the coming Internet disturbances should be viewed as an opportunity to streamline some of your oldest, least maintained, most idiosyncratic infrastructure. In a world where there are professionals who can run most of your applications for you, locally or in the cloud, it's probably time for your organization to move beyond worrying about these kinds of changes. Decommission the old stuff, outsource whatever you can, and the coming problems will largely be problems for someone else, not you.

And that's about the best you can hope for as the Internet endures its growing pains.