The internet is supposed to shift transparently to IPv6 based numbering system soon. IPv4, like a shitty stick, should be dropped as soon as possible apparently. The problem is that there will be a lot of upheaval as this happens. This is topical right now of course.

There are some existing related ideas about how to stretch the length of service of IPv4.I outline here another way to delay exhaustion of IPv4. Indeed you could also take a view that this suggestion could allow for the abandonment of IPv6.

The plan as it exists today

Focussing on just web sites, servers will need to be initially reconfigured to serve up port 80 and 443 traffic on new IPv6 address as well as older IPv4 numbers. All modern operating systems and programming languages have this capability, so it is up to the enthusiasm of deployment engineers for the most part. There is a secondary need for web-developers to be savvy with such things too if they are doing analysis of IP numbers as a form of hacker protection, customer recognition and alike.

In the mean time most dialup and DSL users of the internet will be moved behind NAT, and lose the ability to run home servers with dynamic DNS.End users are 95% of the problem (guess). So for ISPs the issue in IPv4 land is easy, just increasingly move end-users behind NAT. The trouble is that server deployments continue and ISPs are not easily going to relinquish IPv4 blocks as they have eased their their own situation.

A second significant stage will be the phased turning off of IPv4 support for servers as the number of remaining IPv4 clients dwindle.One could imagine that educational and research establishments may be first, and that news media companies would be next to last, and enterprises with crusty capabilities very much last.

End users who have not upgraded their operating system / browser to be able to leverage IPv6 sites, will slowly see sections of the internet disappear for them.The the plan is that everyone big and small gets the incentive to move sooner or later.

Unfortunate side effects

American English has a lovely word gouge. Life in America is all about guarding against being gouged by suppliers, vendors, government etc. IPv4 addresses remaining may float around in a second market like tickets for sports events or concerts do, and we may be gauged on prices for the.IPv4 addresses may or may not be priced at a premium level the original vendor. Additionally existing assigned IPv4 addresses may become more costly to lease on a yearly basis.It may even take the intervention of legislators to prevent the premium pricing of IPv4 address.

Here’s an example: Slicehost sell $20/mo ‘slices’ that have their own IPv4 addresses. What if a speculator rushes in towards the end, and buys slices that they themselves don’t intend to use.Instead they resell them at $200 each, with the buyer picking up the obligation to pay slicehost $20/mo. Why wouldn’t slicehost want a piece of that? They are more than likely to move north of their $20/mo fee going forward. Thus small users of such services are likely to take up a slice-host “offer” of converting to IPv6 early and relinquishing IPv6 traffic. Slicehost have plenty of articles, so they’ll make the migration easy.

The idea: new DNS records to extending IPv4’s life a long way

How about as a delaying tactic? We extend the life of IPv4 via new DNS entries, and upgraded apps to support that. Sure addresses are going to run out, but there is a way for us to share resources more than we’ve done before.Today web browsers look up machines to connect to using CNAME records.If we introduced a, say, CNAME2 record that contained domain name and port information, then we create extra apparent capacity.

Imagine a running FireFox in a Chicago hotel seeks (implicitly port 80). If the FireFox sought the CNAME2 record for, it may see something like:	CNAME2 80:6531

In reality a cloud vendor like slicehost is still going to give you a slice that manages all its own sockets, and listens on port 80 for web traffic, but on the applicable public facing IPv4 address, they are going to accept traffic on port 6531 and route it to my actual slice’s port 80 which will think of itself as an or something.Smart routing is going to get the public traffic to my web server.

The reason you’d do this is because other sites that Slicehost manages are also going to share, but use other ports as conduits to an apparent port 80.	CNAME2 80:6532

Firefox still shows the my site as, but understands that traffic should be transparently routed to

Obviously I’m suggesting that browsers, and other net-savvy tools get upgrades here to handle CNAME2 and fall back to CNAME when not found.

Legacy browsers and operating systems

For end-users that will not upgrade (IE6 folks I’m talking to you) we could just cut them off (CNAME entry goes nowhere). It might be smoother to do a hack instead that makes it work for them too. After a fashion.The regular CNAME record would go to a server that then does a 302 forward to the same server but with the new port number as part of it.Thus the apparent server of to CNAME visitors does nothing other than forward	CNAME

Slicehost mount a server that listens on port 80 and 443, and also redirects back again (using HTTP redirect 301 or 302 or something) to would deploy this for me, and get it to transparently route traffic to 80:6531 so that my actual server will handle the requests.

The downside is that these users will see different URLs to the folks with Updated Firefox/Safari/IE/Chromes:

It won’t hurt them, and it studies are correct, they won’t even notice the difference.

Other ports

Of course ports other than port 80 and 443 are important too.MX records in the DNS system take care of email for the most part, but might not have enough fidelity to push through to the right NATed server. Applications will require upgrades. There are more than you think that speak HTTP to port 80/443 somewhere: iTunes, wget, self-update things, package managers, and many thousands of others. SSH clients will also need to be aware of alternate routing (suggesting that “CNAME” for this entry is not necessarily the best choice):	CNAME2 80:6531 22:6530

There is lots to rework in a matter of months.Lots of code lines to revisit where things have not been designated as end of life (IE7, IE8 etc).

Effort required

As well as apps like Firefox, IE, Chrome, Safari and alike, languages like Java and Ruby that provide networking layers will also need changing. Those changes will need to be pushed to machines That is easy now for Chrome, Firefox and Safari because of auto-update, but not so easy for the sea of Windows XP machines out there with IE6 (hence the workaround for CNAME records with redirect.

One has to weigh this effort against the effort required by network engineers to configure IPv6 infrastructure including IPv6<–>IPv4 gateways, and deployment engineers to get server things either listening on an two interfaces IPv4 AND IPv6 for a long transitional period. The cost to rework Windows, Mac and Linux, and languages per se has already been spent of course.

It seems that there would be a shift in emphasis from network engineers (IPv6 config) to software engineers with this proposition.Will that be well received if true?


It’s going to be easier to not do this in terms of development effort and stick with IPv6 as planned by some committee. I took a career bet that Y2K was not going to be an issue at all, but I think this is going to be more problematic to ordinary members of the public. IPv6 is going to be a mess though; Things are different ten years on.

If we did CNAME2 (and all the NAT tricks for end-users) we could perhaps forget the IPv6 migration. We would also have to watch IANA continued to shake down ISPs, companies and Universities sitting on large blocks of IPv4 addresses that they do not need.

How long does this delay exhaustion? I’m not sure. What is italics: multiply a narrow definition of available numbers by 65536 in terms of years?


December 8th, 2010