Jeffrey Paul

Most big predictions about the Internet look stupid when viewed two or three years after the fact. I’m going to go out on a limb and throw out some predictions of mine for the next five to twenty years.

I’ve been long thinking about the Internet and the applications thereof, and I’ve come up with a number of various theories regarding the future. A small list of them follow.

On 13 August, 2008 on my now-defunct LiveJournal blog, I first wrote that I believe firmly that the IPv6 transition mechanism ([RFC 3056]) known as “6to4 will eventually save the Internet.”

Once IPv6 becomes more prevalent in the datacenter and (non-access) service provider world (which is, comparatively speaking, the Easy Part), many end-users will need and want v6 connectivity for various applications. Access provider networks can be upgraded (unlikely) or, much easier, they can just deploy one or more 6to4 relay(s), giving their customers easy outflow into the IPv6 Internet. The clever idea behind the 6to4 system is that it uses the existing v4 address for incoming IPv6 data to your network, and a predefined address as the destination for outgoing v6 data (192.88.99.1), easily anycasted by your provider. Included for free are a huge quantity (a /48) of IPv6 addresses for each and every individual v4 address. This means that anyone with a single publically-reachable IPv4 address is already capable of being on the IPv6 Internet with enough unique IP addresses to do anything imaginable, including run any of the largest organizations in the world.

The tipping point for IPv6, it seems, is coming into view soon, which brings me to the second one: We are 7 years or less from the day when you can ‘Use The Internet’ as an end-user without a v4 address and not miss too much. Don’t expect access providers to have upgraded all (or even most) of their infrastructure by then, as all but the largest or most shrewd have mostly (and necessarily) all but ignored IPv6 whilst struggling to stay afloat in their highly competitive industry (while per-unit pricing and profit margins both continue shrinking). Even after the time when their customers are asking about it, they can continue to (mostly) ignore it, focusing on maintaining their existing v4 networks and just replacing or flash-updating CPE and adding 6to4 relays in key spots, providing good, workable access with a minimum of infrastructure adjustment. My guess is that v4 provider backbones (serving to support 6to4) will exist for a very, very long time. (Even after 10 years, when end-users no longer receive or want v4 addresses.)

There is a corollary to this, too, which is that if you are an ISP today and have enough customers to warrant office space other than your own basement, and furthermore you are not right this moment providing an outbound 6to4 relay on 192.88.99.1 for your customers, you are Not Doing Your Job. Same goes for NAT router firmware makers that aren’t enabling 6to4 by default (here’s looking at you, Linksys). In case of the latter especially, as the cost is effectively zero.

Also, on the mobile side of things, eventually wireless companies will be forced by the market (like all access providers) to give v6 address, making your handset reachable by the Internet at large and ending the no-externally-initiated-connections bullshit they’ve managed to be unique in pulling off thus far with their NATed and firewalled v4 service offerings.

My next one’s not very unique or clever, but I think people are still underestimating the potential implications. Widescale deployment of IPv6 will enable all sorts of network applications we haven’t thought of yet. Stuff from little things like controlling your heater’s thermostat from your cellphone (or iPad-like-device) to new forms of “cloud computing” wherein the cloud is p2p and comprised of your and all your friends’ WiMax-speaking 1TB-of-flash-memory phones. The potential cool things made possible by restoring end-to-end connectivity are practically limitless. Think big, all the way up to new L4 protocols. These things can replace all sorts of old interfaces (off the top of my head I can think of several, including MIDI, S/PDIF, DMX, infrared remotes, home automation, X10, and DECT, and I’m sure you can come up with more if you ponder it). Now think of them across the WAN, from fixed devices in your home or office to mobile devices that you and everyone you know carries with you all the time, or various iPad-inspired touch-interfaces, sitting on or mounted to your/their coffee tables, desks, and walls. There are some serious implications here when Everything Can Talk To Everything Else.

Today, I’ve got another new one. The coming deployment of DNSSEC will drive all sorts of cool new security applications, and kill off many current ones by making them redundant. According to the operators of the current root name servers, the root zone (the basis for all hostnames on the Internet) will be cryptographically signed using DNSSEC in July of this year.

I think that when DNS infrastructure can provide validated data, people will begin putting all sorts of keys and certificates in there for a variety of apps. Why do you need a PKI for SSL on the web (think of your webserver certificate) when you can put your server’s public key into your domain’s dns zone, your authority for which is signed by the delegating registry?

Another idea that came to me today is that the .in-addr.arpa (and the IPv6 variant .ip6.arpa) zones are quite severely underutilized. While PTR records for IP-to-name mappings are the primary use of this zone presently, there’s no rule that says you can’t have other RR types in here— it’s a DNS zone like any other. Once the zone is signed (eliminating the need for a now-redundant non-DNS certificate chain), you could put the fingerprint of your IPSec opportunistic encryption public key in here… or your that of your SSH service’s key.

Here’s the last one, and is quite radical, and thus the most likely to be flat-out wrong, but I’m going to throw it out there anyway. Right now, we’ve a huge hodepodge of various systems and protocols for realtime communications. Starting with the legacy systems such as phones, both wired and wireless, and the horrible necessity of phone numbers (which predate DNS, a system specifically designed to fix this problem), to various IM protocols, centralized (AIM, MSN, Skype, etc) and not (XMPP/Jabber/Google Voice), SMS (a weird hybrid designed as an overlay on the phone-number system when digital packet-based communications first became widespread), and various other VoIP hackery for backward-compatability, we have to know so much about who and how we’re communicating just to use the options available to us.

I recently found myself explaining to my father about just how much I have to know (and think about) my intended recipient’s choice of telephone handset and service provider when deciding whether to send them an email, email with attachment, SMS, or MMS from my phone. Think about that one for a moment. This process really shouldn’t be more than “send communication X to person Y”. To drop a horribly overused cliché: Think of your grandmother.

Even when everyone has a phone that sends and receives emails and IMs in real-time, you’ve still got to pick which to use by some weird social meta-logic. Presently, I still can’t configure incoming emails (a sound, with no popup) on my iPhone to notify me like SMS messages (sound + popup), or vice versa. All the way from Cupertino, a long social-construct arm reaches out and reminds me of the accepted differences encoded in our cultural implementation of these protocols, even though they’re pushing the same strings of text over the same airwaves. Details aside, they’re still somehow perceived (and charged!) differently.

With IPv6 and a signed DNS infrastructure, I think personal identity (and the communications identifiers tied to them, formerly email and phone numbers and IM names) will eventually be consolidated in DNS. Some will own their own domains, others will use those assigned by a service provider, but all will be relatively static and offer more flexibility than now. Why do you need a phone number when you can have the IP of your VoIP handset(s) in a dynamically-updated DNS record, right alongside your MX records showing where emails to you should go?

Consider the case when your phone’s off or out of the network: Why do you need to have a voicemail service if a user can use the same identifier to send you an email with an audio attachment as they do to make a realtime voice call to you?

(Corollary here: SMTP will outlive you, me, and everyone you’ve ever met.)

This kind of stuff is actually almost possible now, but we’ve not yet seen the collapse of the old models yet. People receiving your business card (an artifact that will never die, if only as a memory aid for hostnames) still expect to find your phone number, not just a hostname backed by an AAAA record pointing to a device ready to accept incoming SIP calls.

With everyone eventually responsible for their own DNS namespace (via various interfaces from identity service providers), my guess is that your email address will become something like *@hostname (e.g. whatever@sneak.datavibe.net), rendering the old user-at-host notation (e.g. sneak@datavibe.net) obsolete, or merely as a tracking identifier, such as the user+extra@hostname (e.g. sneak+blog@datavibe.net) notation of modern-day. Furthermore, when someone receives an email (with attached cryptographic signature) from your hostname, verifying the signature with your key from DNS is a trivial operation. This would certainly be an effective tool in helping combat the huge amounts of spam floating around, too.

Via OpenID or its logical successors, a hostname can serve as an authentication endpoint, effectively enabling Single-Sign-On (SSO) by replacing your username and password pair that you currently provide to dozens or hundreds of different websites.

We’ve already seen the registration (or registration restrictions) for every four-byte (a.bb) domain name in existence, as far as I know, as I’ve been unable to find a one-byte subdomain in any two-byte TLD. For another example, in the .com zone, every single three-byte subdomain (i.e. z6n, 77a, q46.com, etc.) has been registered. I recently had trouble finding a five-byte (aa.bb) domain to purchase, but eventually found a slew of them in the oft-overlooked .tc TLD (named for the Turks and Caicos Islands, a British territory in the South Pacific).

The famous webcomic xkcd was named when its creator sought a four-letter domain in .com using only a-z. (They’re all taken now.) An arbitrary string, but evidence that virtually anything can be turned into a (wildly successful) brand or identifier, given the right circumstances.

When I named my then-new company last spring, I searched for a similar four character alphabetic text string available in .com, .net, and .org. I found one, but the .com variant was already taken had to be purchased from a squatter for a few hundred bucks. Even with that, it still has a ‘q’ in it.

I never really paid much heed to the land rush around domain names (both the first wave in .com and the later ones in newer TLDs and various countries), but I guess I was short-sighted. One day, your hostname (and the other then-authenticated data provided via the DNS) will serve as your identifier for all electronic communications, both for authentication (identity) and reachability.

There are a lot of cool things ahead of us. Until such time that all of this stuff comes true, I can be reached at sneak@datavibe.net (or future_of_the_internet@sneak.datavibe.net after).