Back to: Cage Match! | Forward to: Gadget Patrol: Macbook Air

The internet is full. Go away.

From Techrunch:

The Number Resource Organization, the coordinating mechanism for the five Regional Internet Registries or RIRs, this morning announced that less than 5% of the world's IPv4 (Internet Protocol version 4) addresses remain unallocated. The IPv4 pool first dipped below 10% in January 2010, and in the next nine months some 200 million addresses have subsequently been allocated from the Internet Assigned Numbers Authority (IANA) to the RIRs.

NRO anticipates to allocate the last IPv4 address blocks to the registries within months.

Nothing new here — this has been on the cards for years — but it means the internet in 2011 is going to begin to change.

We've got a successor protocol (IPv6) — it's been around for years, although nobody uses it much. The IP depletion isn't going to affect end users signficiantly in the short term; new/low-end ISPs will probably switch from using a pool of dynamically allocated public-facing IP addresses, allocated one per active customer, to doing some kind of transparent masquerading/forwarding, to increase utilization. This will prevent incoming connections to customers ... but that could be seen as a benefit, not a drawback. However, there is going to be a problem for businesses and folks who want to run servers. Not to mention being a show stopper for Dynamic DNS services, and facilities like Apple's "Back to my Mac" (a part of the MobileMe package that lets travelling users get a remote desktop on their home system from wherever they are). And the inevitable migration to IPv6 is going to cause headaches.

What I want to know is, what kind of headaches? Do we have any networking professionals in the audience?

94 Comments

1:

One of the reasons - the other is sheer inertia - why I'm still with Demon after 15 years is the static IP.

2: Do we have any networking professionals in the audience?

Is this a trick question?

There are a lot of things to consider when going to IPv6, which have been discussed almost to death in the usual circles, basically revolving around the chicken-egg-dilemma, broken stacks and conflicting technical requirements, but all in all we might be in better shape than usually assumed.

The Heise Verlag (running one of the largest tech sites in Germany, heise.de) has switched to dual stack on September 29. this year, meaning that it's main site is reachable via IPv6 and IPv4 under the same name, and has had little trouble with it (or so they say). According to them it's the world's largest dual stack web site world wide.

3:

I wrote something about that to NANOG - a migration plan and the issues that one might have when adding IPv6. BUT, before that, let me say that there's NO incentive whatsoever now for any server operator to add v6 support, because there will be no removal of IPv4 connectivity for the end users in the next 20 years...

(follows a lenghty email I sent on the subject):

Here are the problems with the deployment of IPv6 with a middle-range
content provider and how much of a hassle it would be. Looking at it, my
case at least from the technical POV has the least amount of issues,
compared to some of the issues in office networks or ISPs.

To begin with, we have a single-digit number of routers, double-digit
number of switches, tripple-digit number of servers and about 100gbps of
traffic. There's a bit of in-house software, and gentoo linux as a linux
distro.

1) IPv6 stack support
- recompile all kernels on all servers as by default there's no support,
would require a reboot. It's survivable and can be done in a week.
- the router supports ipv6 (cisco IOS), some research needs to be done
on issues with the V6 and what features will have to be disabled (like
the SSO failover mode).
- Switches don't need to be upgraded, their management can stay on ipv4.

So, this can be done in two weeks.

2) Connectivity
Right now we have 5 transits and 3 peerings. For any normal work i need
two transits to have ipv6, which seems to be possible with at least 3 of
them, but the procedure to negotiate this will be horrible. As the
traffic would be low, I don't care about peerings at this point if time
(and they're not a shows-topper). Also I need to take into account the
current HE/Cogent split in the ipv6 internet.
Also, new configs for the ipv6 part (filters, route-maps)

3) addresses
I have my own ASN and v4 space, I should be able to get v6 easily,
shouldn't take more than a few days. I'll need to touch a bit the db and
scripts that assign static IP addresses to support v6.
(I use only static addresses anyway)

4) DNS
My main DNS is being done by an external company. I need to tell them to
give IPv6 replies for queries that came over v6 only, or i have to move
the dns with me (which I might need to do for dnssec anyway). I think
this is still really needed.

5) Software written by other people
Most of the open-source software we use supports v6 and should just be
recompiled and reconfigured, which with gentoo is mostly portage work.
It will take a week or two to clean up the issues that will arive.
There's currently no known equivalent of geoip for v6, we'll need to
develop something new (like the stuff in ip.ludost.net).
For log analysis we use google analytics, i don't know how this would
work with v6 customers.

6) software that we wrote
Everything needs to be ported to have v6 support.
- most of it is easy, in Stevens' book (Unix network programming vol.1)
there is a lot of good information.
- we have a ftp server that would need to be checked on how we can add
v6 to it (there's probably an extension to the protocol)
- some database tables need to be changed so we can put there ipv6
addresses too. Some of them are really big and it's not certain if we
can do an ALTER without killing everything for a few hours.

This is hell, and would take a few months. Especially the DB part.

7) Tests
We need to find a local connectivity (we're in Bulgaria) so we can do a
full test of everything. That doesn't seem to be an easy task. Probably
we'll have to resort to a tunnel.

8) Support
- kill switch - I need a way to be able to rollback easily and
relatively painlessly back to ipv4-only state. The reason is mostly that
the ipv6 stacks haven't passed the same test of time and scrutiny like
the v4 ones and we can expect a lot of issues like the ones we had with
teardrop, nestea and company.
- ability to NOT give IPv6 replies to specific places because
a) no connectivity to them
b) slow link (some teredo tunnel that's as fast as a dial-up link)
c) other crap in the remote ipv6 stack
- Ability for the people to choose not to use ipv6 to me
- tools to diagnose issues over v6 - looking glasses, etc.

This is fully implementable for 6 months. I can actually be missing
something important, though :)

5:

I've noticed a few sites in the past year starting to place javascript in web pages to test if visitors have IPv6 addressing supported.

Not directly relevent, but FYI anyway.

6:

@Vasil,

It would appear the first week of work required would be totally avoided if you weren't compiling custom kernels with Gentoo. That is, 99% of other Linux shops (some would argue, the sane ones) will not have the same problem.

I *think* 7 is solved with 6to4.

7:

The main problem, as ever, is that no one will be prepared to become an IPV6-only user until nearly all web servers support IPV6, and few web servers will bother to support IPV6 until there are a reasonable number of IPV4-only users.

Then there are all the legacy systems running software that may or may not be IPV6-compatible. For example, FTP is still used extensively (I know why it shouldn't be, but the fact is that it is), and lots of servers and clients don't support IPV6.

Lots and lots of databases, Perl scripts, and so on will make certain implicit assumptions about what an IP address looks like, and will break the first time they hit an IPV6 address.

All of the software implementing the core Internet protocols like ICMP, BGP and DNS has had decades of incremental improvements and bug-fixes; the IPV6 versions have not, and haven't been tested to destruction in large-scale real-world implementations. Expect to see more bugs and security issues as they go through this process.

You're going to see a lot of hacks and kludges to enable continued growth in the ISP market while giving all of their users IPV4 access. I also expect ICANN to allow resale of unused bits of existing allocations -- there's a lot of the address space that, while allocated, is only sparsely used at present. So we probably have a few years more than the worst case scenario under the current procedures.

8:

That should be IPV6-only users in the first paragraph, where it says IPV4-only users. Sorry about that.

9:

Things I know: at the ISP where my server is hosted (kindof a coop, nonprofit), we've had IPv6 for quite some time now, for the most part via tunnels that we got for free to some providers doing testing ..

Since a few weeks ago we also have native IPv6 from one of our upstreams, which is nice. The only problems we see, so far, is that the routing-daemons for ipv6 seem a tad unstable, (istr we use quagga? have to check with others) but that may be because of details of our setup.

Two funny side-notes that I would mention that might make rollout easier:
a) Windows (new versions) does ipv6 without the user even noticing it via the teredo protocol (tunneling). I.e. most windows-users (of vista and 7, at least) should have no trouble accessing an ipv6-only server since microsoft gives them ipv6 addresses via their tunnel
b) biggest driver of innovation (well second biggest after pr0n) on the internet is of course piracy. Note that a few piracy-related things _currently_ are much easier for the user if he/she uses ipv6. mainly the fact that you can get free access to fast binary news-servers with long retention time via ipv6 ... (by fast I mean 2 Mbyte/s or so, probably limited by the teredo tunnel endpoint)

10:

on the allocated but unused IPv4-space: istr a map on xkcd? ah yes http://xkcd.com/195/

I mean all these companies who have /8 nets from way back of course look like ripe targets (hah) but otoh at the current growth-speed will merely stave of the inevitable by a short time, imo.

11:

I work at a large, research-oriented UK university, and the team I'm in runs the network. Our experience has been that, in all honesty, IPv6 is not that hard. It's different and will require a bit of re-skilling, but frankly most network engineers I've met are either a) capable of doing that in a couple of months at most or b) not really network engineers.

I realise other people won't agree - that's fine. This is a topic on which reasonable people can disagree. I'm not going to get into a bun-fight with you - let's revisit the topic in 5 years and we can *see* who was right.

Older equipment (in particular ASIC-based routers) is an issue, and certainly I'd expect a 5-10+ year period of mixed 4/6 connectivity, but good transition technologies (NAT64) can help a lot.

It will be quite some time before major content servers can afford to be on IPv6-only, but I think we're only a couple of years away from seeing IPv6-only client networks with v4 connectivity via a translator, which will return some v4 space to the (sure-to-develop) market. Of course, once clients are v6 enabled there is some benefit to enabling servers, to avoid the bottleneck/source-address-hiding of the translators.

The wikipedia article on 6rd gives an indication of how this might happen, although the extremely poor quality and "make, sell, forget" nature of CPE (i.e. ADSL routers) is a source for concern there.

(Ironically the "synthesise AAAA DNS response pointing to a v6->v4 translator" approach comes just at the time DNSSEC is starting to get traction, so we'll obviously have to crack that, but I'm confident that's do-able)

To answer Charlie's question directly: most likely, the migration to IPv6 will result in a few old (and some new) IP stack bugs rearing their head. There will be cases of client/server pairs whose IPv6 connectivity is broken - these will probably manifest themselves as 10-30 second pauses the first time you hit a webpage (the browser/app/dns cache will probably store "broken v6" flags for subsequent connections).

There will almost certainly be a bit of whingeing about "NAT is a security feature blah blah" but I expect that to trail off.

In short - nothing earth shattering. TBH most people will probably see far more problems from the collapse of the 3G networks, which have gone from "ooh shiny" to "WTF where's my data signal" as the JesusPhone sucks up all the spectrum ;o)

12:

Okay, all I need to know is just what month that will be, so I can craft an alarmist headline about the internet breaking sometime this year.

13:

ArsTechnica recently had an article about the upcoming IPv6 transition: There is no Plan B.

14:

My own IPv6 experience is very limited, just setting up a couple of HE tunnels to see what the state of things was.

However I think the major headache for many won't be the network stack, it'll be the applications. By this I do *not* mean the socket API. I mean anything that deals with IP addresses. It'll all be assuming dotted-quad/32bit right now and not only needs an update to even be able to store IPv6 addresses instead along with parsing code updating... but also needs to remember and know some things about how IPv6 works. i.e. fe80:: prefixes are link-local, how the MAC-based IPs work etc.

I still need to sort out both daemonshield.py that I use at home and the custom script on a server I help run to even consider IPv6 addresses when it comes to dropping packets from nasty addresses that have been trying dictionary password attacks. Perhaps I'll just see what else there is that does this sort of thing and if anyone else has bothered to add IPv6 support.

Which is a thought. I do hope there are companies who make general 'network software' that are pushing hard to cover IPv6 and try to capture market share....

15:

I have the impression (based on nothing else than reading NANOG religiously) that adoption of IPv6 is beginning to pick up, just on the basis of the people who pitch up and ask if they should number point to point links /64 or /127 and the like.

There's a nice security issue with Router Advertisements, IPv6's dynamic configuration feature. Basically, routers send out RAs to the hosts on their network and the host picks the router it configs. Unfortunately, if you can figure out a way of injecting malicious RAs into the broadcast domain you can masquerade as a router and do a MITM attack. Come to think of it, it's a bit like "Free Public Wifi". So you need to "RA Guard" and filter them.

A surprising amount of stuff is already v6'd - recent Windows come with it on by default, and Microsoft run their own Teredo relays as a default for them. Apple Airport Xtreme boxes are on-by-default as well and Apple has a pool of 6to4 relays for them. Of course, all your traffic going to Cupertino and back is suboptimal.

And we keep finding weird things in the IPv4 Woodshed - earlier this year, when 1/8 was allocated, RIPE NCC announced it in order to debogonise the block. They got knocked flat by the volume of traffic in there and had to ask Google to sink it for them. When they analysed a sample of captured traffic going to 1/8 addresses, they discovered all sorts of weirdness. 90-odd % of the packets were heading for either 1.1.1.1 or 1.2.3.4. The whole Hamachi zeroconf VPN network was squatting in there. And T-Mobile Netherlands was leaking remarkable amounts of MGCP traffic (that's Media Gateway Control Protocol and it's to do with voice and IMS) into the global Internet.

16:

I work on the forwarding path of fairly large routers (the type more likely to be in a telco POP (point-of-presence) than an enterprise or in the Internet core), but I don't usually see much of the running of real networks (other than inside my household of three). So the grain of salt you need for my comments should come from the bit-level salt shaker.

That said, it's pretty clear that the challenges will be different in different places. v6 adoption is a lot more advanced than most English-speaking people realize, just not in their countries. Areas that only started getting substantial Internet penetration in the last decade may well be running a lot of it already. Large companies may be running it internally -- and many of those are ready to cut over to making it primary.

In my own area, the gear for network infrastructure, there isn't much of a problem. There have been IPv6-only markets for some time, so we know they work. There may be some features available under IPv4 that aren't under IPv6, but that kind of thing can be fixed pretty quickly if and when someone cares. Forwarding IPv6 is nominally slower than forwarding IPv4, but in practice there are few problems, and no serious ones. [I can expand on this, if necessary.]

Problems primarily come from issues in having v4 and v6 co-exist. Some of these are essentially NAT (or protocol translation in general) problems, as Charlie pointed out up front. This is generally similar to the problems NAT has always had, and so far it seems like we'll have to deal with them the same way.

One of the big problems with moving to IPv6 right now is that a fair number of domains have broken DNS records for IPv6. Obviously, these are organizations that aren't actually using IPv6 themselves, so they haven't had an incentive to fix it. Their incentives will change as they have to deal with more people without full IPv4 access, but it's anyone's guess how long that will take.

A really tough co-existence problem is IPv4-only hosts dealing with IPv6-only hosts. The former exist in large numbers now, and the latter will exist in increasing numbers because new networks will be using IPv6 because they can't get IPv4 connectivity. Getting around this will require explicit translation services; inconvenient at worst for most of us, but more of a problem for less knowledgeable users.

I should also point out that IPv6 has been coming scarily soon for us equipment vendors for some time now. Over 15 years that I've been dealing with it. This time for sure...

17:

From what I've seen businesses are rather slow to adopt v6 if they haven't understood yet that networking *is* one of the core functionalities they need (trust me, there are lots of those out there still) and that *now* is the time to start with v6, not when the bovine herd starts their stampede.

In my eyes of the bigger showstoppers is lack of dynamic DNS registration with IPv6 autoconfiguration (this doesn't seem to affect Windows so much as Linux and, IIRC, OS X). One does *not* want to remember an autoconfig'ed IPv6 address... :)

18:

Mass migration to IPv6 is basically impossible, for one simple operational reason. The only scenario that was envisioned by the groups working on it was dual-stacking. IE people get connected to both IPv4 and IPv6, and when they all have IPv6, they switch over.

It can't work that way.

In practice, typically, the few people who have both often find out that IPv6 does not work for them or not that well; not because it's inherently bad, but for one reason: it does not matter.

Say a fault occurs on a network.

If it's IPv4-related, people are inconvenienced, they complain, it gets fixed eventually.

If it's IPv6-related, people usually don't noticed, or if they do, are told to use IPv4 instead. The problem goes unfixed for a long time. When people try to use it, it doesn't work, they give up, but they don't need it anyway because IPv4 provides the service anyway.

When Google rolled out IPv6 support, they had to implement all kind of hacks because IPv6 is broken for many users -- and they don't even notice.

There is only one way IPv6 can begin to be used. It requires carrier-grade NAT, so that IPv6-only nodes can talk to IPv4-only nodes. I think it's called nat64. It's being worked on last I checked, but very late in the game, which is a shame.

Dual stacking is a losing proposition, things will only move forward when you can start using v6-only clients. I believe this could happen the fastest in the mobile space. There are several problems here:

1. Mobile carriers are dumbasses, and don't understand the net. They don't have the competence to implement this properly.

2. They are also not interested in the peer-to-peer capability that IPv6 would open, they're most certainly just fine with having people under 10.0.0.0/8 and block anything.

3. Many mobile OSs are simply too bad/closed to handle IPv6. Linux and iOS are probably the two exceptions.

4. But even Android is often unupgradable thanks to oppressive carriers / handset makers.

19:

There are lots of reasons, but they boil down to two things: ubiquity and complexity.

If I want to run a v6 server, everything necessary for the connection has to support v6. Of course that means transit, both from my ISP and within my organization. But my firewall has to support it, my intrusion detection system, the geolocation server I use to restrict access to geographically-restricted content, the targeted ad servers, and more. If even one of those is missing, I can't use v6. By contrast, a client with v6 available can use v6 if available on the site you're connecting to, and fall back to v4, even NATted v4, if necessary. Generally, that JFW (just works).

Servers are also far more complex. Do you log IP addresses of sites that connect to you -- and does your log file analyzer handle v6? Do you use a database to track address assignments within your site -- and is the address field big enough and properly typed? Does your own code -- and servers are much more likely to have custom code -- handle both types of addresses? Even your web server may need special configuration, especially if it runs multiple virtual servers. To a first approximation, clients are all alike and servers are all different. (The one thing you may not need to touch is your OS. All modern operating systems support v6 out of the box. If your OS doesn't support it, you're probably due for an OS upgrade anyway...)

Let me add one more point: reliability. A server needs to be available all the time, for all clients. New circumstances tend to reveal new bugs.

20:

@phil #9 :

Old applications should not be an issue; for a simple reason: they are NEVER going to be upgraded anyway. Well some of them are, but never all of them. Never, ever. Even thinking about upgrading them is stupid. It's not going to happen. I'm a sysadmin in a corporate environment, and I can bet you $1000.

The solution would simply be to treat IPv6 like you treat NAT. Give IPv4 only hosts a private address and NAT the fuck out of them. The only things that *would* need upgrading on a corporate network, for example, wold be the proxy/DNS at the edge.

Even in a home network, a decent cheap router should be able to handle this for its clients.

No, the real problem lies at the IPv6/IPv4 interoperability, and the reliance on the unrealistic dual stack "solution" has hindered the development of the NAT thing I'm talking about.

21:

@6: "I also expect ICANN to allow resale of unused bits of existing allocations -- there's a lot of the address space that, while allocated, is only sparsely used at present."

All too true. There is a large US corporation I worked for briefly that has one of the low number class A networks assigned to it, and they use it throughout the company network *but* they also have a policy that no address on this network will be visible to the public, and all externally visible machines tend to sit on extra /24 networks. Ergo, they're occupying 16 million IPv4 addresses which could freed up simply by changing the first number in all their addresses to 10 so they use the RFC 1918 class A network.

However, that's only 0.4% of the address space, so wouldn't last long.

22:

I currently consult for .SE, the Swedish TLD registry. One of .SE's functions is to try to predict what's going to happen with the Internet in the future, promote good things and try to help prevent bad ones. Which means that we've been working to make sure things work with IPv6 for several years now. You've already had many opinions on that, so I'll just put my voice on the "it's really not that hard" side.

But there is one thing with IPv6 that might interest you: large-scale adoption will likely happen in reverse order from that in which countries came onto the Internet in the first place. Since the US were first out, they have most the IPv4 addresses. China was late, so they have few. So it's no surprise that the first large-scale live use of IPv6 was the Beijing Olympics in 2008. China and India will _need_ v6 before we do. I suspect that one driver for western companies to adopt IPv6 will be in order to be able connect with Indian or Chinese companies they want to do business with.

Even so, IPv6 is not that big a deal. Once it's in place, almost nobody will care about it any more. It's only the transition period that'll be a bit interesting.

If you want something that may actually change things, have a look at DNSSEC.

23:

Just a little clarification: the MobileMe Back to my Mac feature has always used IPv6 tunnels, as far as I know. I don't think it's going to be affected at all by the outage. (But it /is/ affected by things like PowerDNS installations at your ISP being unable to register your machine with this service if your MobileMe user name contains a "." character. Le Sigh.)

Anyway, I say bring on the IPCalypse. 2011 is going to be fun and exciting for a brief period of time.

24:

The biggest remaining hurdle I see to widespread acceptance of IPV6 is that virtually all home routers are IPV4-only.

Yes, I am aware of replacement firmwares that you can install that will support it, but we really need something that supports it off the shelf.

25:

Short term, v4 addresses already in possesion of RIRs will become valuable. You can hardly trade small blocks without causing routing mayhem, so I expect establishing some kind of commercial clearing centers. Depending how fast v6 will roll over, these can gather lot of power and no oversight.

Other thing that pops to mind is having different data available in two different networks. Once 4 is overthrown and 6 becomes "the internet", any number of glitches may make old bridged v4 content invisible or lost to general public, but still accessible to knowledgable person.
This especially applies to security. I expect lots of hacking through legacy interfaces, enabled by default because of backwards compatibilty, but forgotten or unknown to users.

Yet another security thing is vanishing of NATs - zillions of home users using NAT as means of simple firewall will be forced to wake up. v6 is gonna make proper firewall configuration more complex, yet cheap "public" addresses will be much more utilized.
My bet is on less blocking and more intrusion detection, creating it's own market vastly different from current AV sollutions.

26:

And NAT on a large scale will continue, with organisations continuing to use 10. networks internally whilst presenting a limited number of "real" IP addresses to the internet at large. Inertia will continue to be the biggest problem.

27:

It's worth noting that there are significant parts of the Intertubes that run IPv6 already.

ComCast's backbone for instance: Rumour is that they ran out of space in 10/8.

The majority of problems will be the usual stuff:

A) the usual trouble with software updates

B) badly written software

C) security holes

But the majority of costs will be planned obsolesence of stuff that is not IPv6 ready: Printers, IP-cameras, Win98, and likely when it comes down to it: WinXP.

Poul-Henning

28:

There's only so far you can go by sharing out the 'unused space' in the IPv4 space: If you split a class A into 65536 Class C's then you're going to fill up the routing tables in the routers pretty quickly. I've been out of the networking game for some years, so the exact numbers will have to be given by someone else, but you'll hit a slowdown in the routers before you hit actual exhaustion of addresses.

Ultimately it'll be a race between nat64 (for reasons already stated) and effective collapse of nat'ing of IPv4 systems: the more addresses move over to 1918-space, the more likely apps (especially peer-to-peer) break due to NAT'ting and NAT servers dying (almost no-one does NAT failover, which means one NAT server goes and everyone 'downstream' is disconnected.)

For me the question is, where are all the proper IPv6 firewalls and security? I can get IPv6-capable home devices but not IPv6 firewalls, the last I looked. People currently rely on NAT (a technology designed to allow as many as possible through an address) as a firewall (the opposite). When they break or go away, what happens?

29:

@25: there are IPv6 enabled firewalls out there. One of the larger home box providers over here, AVM, has an experimental firmware for their flagship box for a few years now. They started offering IPv6 capability out of the box recently.

Linus devices have ip6tables. Considering Linux is the base for most of the consumer and SoHo routers nowadays, this will be getting more prevalent on the UIs as well.

Commercial grade firewalls support IPv6 as well (I know of Juniper and Check Point, but I suspect all the major vendors do by now).

How effective they will be is another matter - IPv6 has a few fundamentally different concept from IPv4 and it remains to be seen how those firewalls cope with that (or rather: how much the engineers managed to wrap their heads around the changes in the protocol and network flow).

30:

I'm not a networking professional, but I found this article useful in understanding what's going to be difficult about the IPv6 transition:

http://arstechnica.com/business/news/2010/09/there-is-no-plan-b-why-the-ipv4-to-ipv6-transition-will-be-ugly.ars

31:

does this affect news feeds? we usually get the realtime ones several days in advance...

32:

I also recommend the Ars Technica article about this. (Initially recommended by Rhett in comment #27)

33:

@ 8
A HUGE number of businesses, and private users refuse, point-blank to use MS Windoes 7 or Vista - they are still all (like me) on XP, and don't want to change, since the others are known to be inferior.
(Well-done MicroShaft!)

34:

For what it's worth the IPv6 stack in WinXP SP3 is passable; the major missing component is DHCPv6 and there are 3rd party clients for that (dibbler). So, if you choose to stick with XP that need not be a barrier to IPv6 deployment.

35:

The biggest problem will be end-user apps. The routing isn't that bad, although there are still goofy things like autoconfiguration/dhcp/MAC-based addresses that cause complications. The APIs for IPv6 and IPv4 are just different enough that it's difficult to transparently handle both IPv4 and IPv6 connections with the same code - and different OSes manage that 'transparent' support differently. Then there comes the bugaboo that lots of code claims to support IPv6 but has never been adequately tested in the myriad combinations of 6-to-4, 4-to-6, 6-4-6-4-6, etc.

36:

Unfortunately, IPv4 address starvation really is bad for the Internet. Your premise that we won't notice, and might benefit from, massive NATting ignores one unfortunate technical detail, which you've probably noticed but perhaps not registered: NATs only give you a 64k expansion on addressability.

Your NAT has a big table in it mapping your connections to a real IP address/port combination. Everybody else behind that IP address is in the table too. When the table gets full, bad things happen. Connections get dropped. You get broken picture icons. Stuff like that.

This is something that you can see pretty clearly in Google maps or on Facebook, because they are so connection-hungry. As more and more devices get crammed behind NATs, stuff like this begins to work less and less well.

Eventually, only connections to hosts at your ISP will work well--connections to the outside world will be chancy at best. In effect, you'll be living in a walled garden, just like in the AOL days, only now your ISP won't have to run you through a portal to make you switch to their walled garden--you'll do it because it works better, and probably won't even realize you've done it.

How difficult is it to run IPv6? The bottom line is that for someone who's reasonably tech-savvy, and isn't running a huge back office, IPv6 is dead easy. As long as you can get a connection. If your ISP doesn't offer one, you can get one through Hurricane Electric or Sixxs.

You will probably lose a small percentage of your traffic if you just turn up IPv6--that's what Google claims, anyway. Their explanation is that broken IPv6 connectivity sometimes leads to hosts requesting AAAA records, and trying to use them, and timing out for 90 seconds. I see this sometimes if I'm connected to a badly-run IPv6 network.

That said, I have been running IPv6 native on my servers for several years now, and have not received any complaints, despite having a fairly naive user base. I think it's a non-problem unless you are Google.

As for using IPv6, experiments in NAT64 (http://arkko.com/publications/ietf78_behave_nat64exp.pdf) have been very successful, meaning that you can run a V6-only host that connects to IPv4 hosts using IPv6 as a transport to your NAT. The win here is that it means you only waste IPv4 connections on things that *can't* connect via IPv6.

So there is a way out of the horrible Internet walled garden meltdown of 2012, and that way is IPv6. Let me know if you need help setting it up--I'd love it if I could reach your blog via IPv6. :)

37:

IPv6 is starting to uptake even without the the number allocation pressure, for the following reasons.

The US government's internal networks, especially the milnet and siprnet, are now routing IPv6, and in another couple of years will be requiring program managers and application sponsors to request waivers (with groveling explainations) of why they should keep using v4

Some very large ISPs, such as Comcast, have RUN OUT of RFC1918 address space for their own internal network management. Every cable modem as a provider-side IP address, in addition to the one that the customer sees, and it has turned into management nightmare because their own internal network managment systems can't get end to end visibility of their own property.

The successor to GSM, called LTE, is yet another example of "IP eats everything", in that it is not a wireless telephone circuit with IP on top, but is instead a way to wirelessly pump IP datagrams, and voice is just a SIP application on top of it. But the LTE specs dictate IPv6, not IPv4.

The Chinese and Indians are sick and tired of trying to keep over 2 billion people NATed behind half a dozen class A addresses, and so are pushing hard on IPv6 on their IT staffs and telecom vendors, and whines about "its hard and different" are greeted with angry uncaring, as it should be.

Similarly, I have angry dismissmal of whines of "its hard!" from IT staffs and CIOs in the US and Europe. Bluntly, if you don't understand your network well enough to start running IPv6, and if your hardware is so old, or un-updated, as to not be IPv6 ready, you are incompetent and need to be fired.

38:

There are two Internets. Version 4, and version 6.

The usefulness of a network is a function on who you can talk to with it. At the moment, most people are plugged into just the version 4 one, with only a few people using 6.

(And those uses of the 6-net are usually simultaneously plugged into the 4-net. There are few people running on just the 6-net, and most of them -- so far -- aren't important to most people.)

My expectation is that, at some point during the next 18 months, IPv6 adoption will take off, hard -- and that, relatively suddenly, there will exist important, useful services on the 6-net that users with only 4-net connectivity can't (natively) get access to.

This will likely result in a likewise sudden priority jump from 'meh' to 'screamingly important, z0mg, deploy support ASAP!' in various organisations as they realise there are important network destinations they can't (efficiently) reach.

(Whether the 6-net infrastructure will gracefully cope with such an uptick in demand is another question; I suppose we'll see..)

Those technical groups that have planned for such an eventuality -- ideally having had IPv6 connectivity and tooling support up and running for a year or more -- will likely do well.

Those that haven't.. may well be in the market for network consultants who can hook them up in a hurry..

39:

I just did an upgrade of my hardware, but since XP still works, I carrying on with that for a while: my machine was old enough that I needed to replace a few too many bits, and why spend so much money on Windows 7. But I don't see reports of it being dreadful. Not like Windows ME or Windows Vista, anyway.

I wonder how Linux+WINE will cope with IPv6. Is that thought crazy?

41:

What we need is for the next killer file "sharing" protocol to require IPv6.

42:

windows 7 is way way better than vista,
its like the pretties and features of vista at xp speed- its also the first microsoft OS I actually paid for rather than pirated

43:

That's already happened: there have been and still are commercial Usenet service providers who provide free, fast access to their article stores over IPv6.

Coupled with NZB digests, client-side tooling and web-based indexers, it offers an attractive -- though more challenging to set up -- high-performance (and harder to monitor) alternative to BitTorrent.

44:

The company I work for started working on moving to IPv6 about five years ago. About three years ago it was mandated that any services must support IPv6, or where it was an externally developed tool, have it in the roadmap before 2010. The new XMPP server I deployed this year is only advertised to the internal network with an IPv6 address - nobody has noticed.

There's been very few issues. Getting external providers and clients to consider using IPv6, is of course, a complete nightmare.

45:

Lots of organisations - and even ISPs - will use NAT to avoid moving wholesale to IPv6. That means that to access the Real Internet, most people will traverse two stacked NATs; the one in their own router and the one their ISP uses to hide the fact that it's using either RFC1918 internally or (more sneakily but probably more likely) is using the same netblocks in two different parts of its network. This kind of thing gets referred to as "carrier-grade NAT".

This is probably going to make unusual UDP-based protocols and totally traffcless TCP sessions suck tiny rocks. It may also means that some protocols that don't easily traverse NAT may not work so well, and the ones your ISP is not (for whatever reason) inclined to help make work will be bad news.

Amusingly, I'd expect that this won't happen for file-sharing protocols in areas where customers can simply choose an alternate ISP; since people would just hear from their friends that ISP B makes eDonnkey (or whatever) work and ISP A has a problem with it. This puts ISP B in an interesting position though; they have taken steps to make that protocol work, and I have no idea what that means for them legally when the lawyers knock. Probably it'll make them extra-anxious to cooperate in order to avoid being accused of abetting (erm, IANAL).

Rollout of IPv6 will certainly precede the technologies that track it. IP geolocation will start to suck more. You will get offered web pages in Dutch even though you live in Italy. Some of the spam blacklists will fail to keep up effectively. Some similar systems will just not make the transition because nobody got around to re-engineering them to deal with IPv6 (2^32 bits easily fits in RAM; 2^128 not so).

Content delivery services will become more expensive. The shops that do it badly for IPv6 (its essentially a geolocation technology) will perform less well as the rollout continues. The shops that do it better will be in a position to charge more. People will suddenly start to see the point of Google's DNS protocol proposals.

46:

Any website that assumes that IP addresses are unique per visitor (e.g. counting "votes" for web polls, or blocking spammers) breaks once you start doing Carrier-Grade NAT (i.e. address pooling), because your external IP address is the same as your neighbor's address.

Of course, this assumption also breaks, differently, with IPv6, since IPv6 autoconfiguration means that it's fairly trivial to come up with 2^64 distinct IPv6 addresses for yourself.

47:

Carrier Grade NAT (CGN) is covered in detail here:
http://www.networkworld.com/community/node/44989
The gist of it is that you do stuff like the private 192.x network address we have now at home, but do it at the edge of the ISP. So everyone with AT&T in Y part of your city gets 192.168.Y.x. This is another way to extend IPV4.
For discussions of the problems with dual-stacking and the move to IPV6 refer to networkworlds earlier post:
http://www.networkworld.com/community/node/42436

The problem of course is when does your ISP start allowing you to get and pass IPV6 traffic? Let alone the other problems:

(1) all those dlink, belkin, linksys, etc home routers that were sold over the last few decades.. how many of them will be able to updated? (tech knowledge to do so or supported at all) Side comment: check out supported routers on DD-WRT or Tomato and see re-purposing old routers for IPV6

(2) dual-stacks (IPV4 and 6) still need IPV4 addresses to pull it off, and uh-mm we are out of those.

(3) NAT is now well known enough to be worked around with port forwarding, STUN and other means (wasn't that way 10 years ago). But when you get to IPV6 we no long have NAT... (some proposals to extend NAT to IPV6 are being debated) So think of that security via obscurity that we have gotten used to by having our home machines hidden behind statefull firewalls + HIDDEN IP addresses + closed ports. This will no longer be the case.. your machines IP will be addressable via the internet, best hope you have a secure firewall installation on your machine.

48:

My prediction on the main "public affecting" (read "written up hystreically in the media") issue is going to be SSL certs for small websites.

Currently, each domain protected by https (technically SSL/TLS) requires a unique IP address.

When new IPv4 addresses stop being available, small businesses are no longer going to be able to use https://www.elided.org for their secure website, and will possibly resort to using a shared secure cert of something like https://elided.org.sharedcert.isp.com - which isn't a problem in itself, but then the scammers will be free to register domains like securecert-isp.com and putting up phishing pages on (secured) domains like https://elided.org.securecert-isp.com and all the old advice about "look for the padlock" combined with the new advice of "yeah, it's OK if a website's checkout page is on a different domain" will lead to new opportunities for fraud - which the media will hysterically report (either because "the great unwashed" will be getting fleeced by scammers, or because "web security companies" will be touting for business by planting carefully worded misinformation in reporters ears...)

49:

I tried to read the arstechnica article, I really did. But it was boring and I got distracted by something more interesting:

See the URL on my name above.

This tells of the battle between music publishers and file sharers. It IS relevant to this thread because it raises questions about whether an organisation like anonymous can be so under IPv6.

Also, note that the industry is perfectly willing to use DDoS attacks when it suits them. How do they do this? Do you have any sony SW installed?

50:

> they are still all (like me) on XP, and don't want to change, since the others are known to be inferior

I usd to be one of those but frankly I was wrong because going from WindowsXP to Windows 7 is pretty painless for the home user and not so bad for a company. 7 is better than XP, hands down.

There are definite problems for some companies where they're supporting huge legacy systems written in, for example, VB6, that can't be simply or easily ported and have to be rewritten from the ground up but none of it is insurmountable it's mostly inertia and cost saving in a recession.

51:

bittorrent aggressively seeks out IPv6 connectivity because it punches through NATs...

52:

I'd suggest this is a godsend to the smart network admin. At just the time when bosses are trying to tighten the purse and even get rid/outsource the admin, here is a rerun of Y2K to keep things safe for the next few years.

Step 1) Highlight the issue and the expected progress of problems over the next few years.

Step 2) Provide a structured plan to move the organisation from IPv4 to IPv6 over a period of 3 years ('to minimise the impact on the budget sir'). Get signoff.

Step 3) Implement over 4 years, using the budget and the uncertainty to keep your job, when all around you are losing theirs.

Step 4) Profit, or at least break even.

53:

In response to commenter @2:

Google has been running an IPv6 stack for a while (March 2008- see http://www.google.com/intl/en/ipv6/) which allows you to do web searches. Google.com is probably bigger than heise.de.

54:

Something I forgot to mention in my post above.. There's a problem I had to fight when Linux first rolled out IPV6 support and we should expect it on other OS's also.. Namely if you are searching for an Internet service in a world of dual stacks (IPV4 and 6) where some are and some are not, timeout issues will crop up.

Namely how long do you wait before you timeout an IPV4 search and then try an IPV6 search for that service?

Do you try IPV6 first and wait to timeout from that site if its not available? What's supported at a site and what order you try IPV4 or IPV6 connects will have adverse effects on the perceived performance of connecting to that network service...

I suspect a default 3 minute wait on a socket connect will be considered poor form..

55:

I have a feeling that may have started hitting me--somehow I shall have to check what my ISP is doing--because some web pages return some sort of error, such as 404, and some have nothing happen until the timeout. One of the latter is a .mil, which has been mentioned upthread as running on IPv6.

(I wanted to check the "Stars and Stripes" archive for a particular Bill Mauldin cartoon. Their own link didn't work.)

If this sort of v4/v6 conflict changes the way error reporting happens, people may notice.

56:

Vista was horrible.

As a 64-bit Wintel OS, Windows 7 Just Works.

57:

Do both, and whichever answers first, kill t'other?

58:

It occurs to me that the way to get IPv6 adopted is to make porn sites IPv6 exclusive.

And then tell the politicians that you've taken away their dotted-quad addresses. Everybody is happy.

59:

I'm responsible for just under a hundred Vista 64 machines (we needed a 64 bit desktop Windows OS, 7 hadn't been released yet, and XP x64 wouldn't run some of our software).

They've been utterly fine. This may be because they were deployed after Vista SP2 was released, but they've been reliable, secure, and are pleasantly snappy to use.

I'll probably build a Win 7 image and start deploying that for new users some time next year, but I'm in no hurry to do so.

60:

I installed Vista onto a partition on a machine that had originally been sold with the XP + upgrade package. So it will have been pretty much the first release of Vista.

I ended up always booting to XP instead, until such time as W7 turned up - I then wiped the Vista partition entirely and put W7-64 on instead. Vista has always refused to recognise a fair chunk of the hardware.

The only time I see XP now is on this work PC, and I don't think we have any Vista machines in the building.

61:

Do both, and whichever answers first, kill t'other?

Indeed -- see the proposed "Happy Eyeballs" recommendation for this. The idea is to take the "do both" idea, but gradually learn which protocol works better, and switch to using it exclusively.

62:

In other words, if a task is intrinsically parallel, don't serialise it.

(I need to do a code change or two along these lines myself, mind.)

63:

This comment doesn't add to the discussion, but I'd just like to point out that Charlie asked if there were "any networking professionals" among his readers - and got Steven M. Bellovin.

Heh.

64:

something that just occurred to me: cable-internet providers (at least here in Germany) have only this year started to roll out DOCSIS 3 as the standard for their networks (thereby allowing bandwidths of up to 100 Mbit/s downstream). Meaning there's a lot of new hardware that has been sent out this year and that still has to earn back its cost. From what I've heard not all of those cable-modems are ipv6-capable. D'oh.

Guess that's one of the things on my todo list: ask my home provider about their timetable for native ipv6 for end-users (given that I just switched to a 50 mbit connection, which is nice).

65:

I've worked on both a telecommunications server and a content management system, and at both employers I asked around about our support for the switchover to IPv6. Both times I got the same answer: the software worked fine with pure IPv4 or IPv6, and was functional in a mixed-mode environment but with a few annoying problems.

66:

When is this really going to happen?

Maybe that's just one of the questions the real old-timers ask, but are you sure that's real? The company I work for is (in international terms) just a two-bit operation, but we can still easyly get an additional B-class public network today, and not at some stupendous rate.

Until only some ten-something years ago, we had to make do with only 8. NAT and Masquerading will go a real long way today, as you suggested, and that is before the first participants in IPv4, which happen to be mostly starved-for-money public institutions that got huge allocations (like several hundred public IPs for each connected computer just by asking) start peddling out their pools.

Now, multicast was a great idea ten years ago. It would relieve network load a great deal, if the concurrently consumed bandwidth didn't scale linearly. More so now than ever, just look at what sporting events do to a national network. Do you know any (large) provider that will provide multicast? I don't. You all know what the excuse is. As long as only we provide it it's no good. And they're right. Multicast only works End-to-End (does that term warrant capitalisation?).

Going on for some twenty years now they haven't been able (or willing) to set up their networks to handle multicast. Maybe this is not a coincidence but a pattern. True multicast wouldn't (correct me if I'm wrong) allow individual user tracking for the broadcaster. Multicast is a built-in for IPv6 (correct me if I'm wrong again). Therefore in today's environment it's Something Large Corporations Don't Want Fullstop. Capitalisation intentional this time.

THEY won't allow it.

67:

sry.

End-to-End among providers that is.

No use pointing out the spelling mistakes. easyly done putting them right in your head. It's late.

68:

IPv6 has all the same security flaws as IPv4, plus new ones specific to IPv6 - and in *hexadecimal*.

The consonance of the English letters 'B', 'C', 'D', & 'E' will result in tens of billions of USD is outages, misconfigurations, security breaches, et. al. over the years, assuming IPv6 is ever widely deployed.

The horrendous amounts of state being wedged into the data-plane in the form of IPv4 Carrier Grade NAT (CGNs) and 6-to-4 gateways will result in even more deliberate and inadvertent DDoS attacks (DDoS attacks are attacks against capacity and/or state).

All the essentially unfilterable ICMPv6 message types enable even more DDoS vectors.

And so forth.

Personally, I think that we'll see IPv6 deployment in some applications/regions (mobility in APAC, for example), but that rationality will finally take hold and we'll end up w/IPv10, which will actually resolve many of the fundamental architectural flaws of both IPv4 and IPv6 (the term 'IPv8' was poisoned by a NANOG troll calling itself 'Jim Fleming' years ago). The LISP effort will succeed, meaning that it ultimately won't matter what transport is being run in various networks, as the LISP ITRs will translate and glue them all together (http://tools.ietf.org/html/draft-farinacci-lisp-12).

69:

One can deliver email to me, and read my web page via IPv6, and one has been able to do that since around 2001.
Weirdly, I've never had to recompile any of my kernels to enable IPv6. (Well, I've recompiled them to include IPv6 without it being a module, but that's because I thought it was so important)
All very nice posts, except that 80% of new deployments in India and 95% of deployments in central Africa are IPv6-only.
At my work, we use IPv6 for everything and except for one grey beard that refuses to enable DNS on his Sparc 10, everything just works.
CGN will occur. The companies that use it instead of IPv6 are the ones that you should sell short. The ones that use it as part of NAT64, will be turning it off as fast as they can.

IPv6 is the stuff that Halting State is made off. That's only 8 years away now, and IPv6 has been running on my network for that length of time already.

I just finished Fuller Memorandum. Nice recursive possession. I love it... but did you know that:
B.O.B. === BOB p0wnes BOB?
(Dual recursive acronyms... Like...
TATO = TATO and TATO Only)

I was disappointed that BOB didn't remain possessed, that would have been given him superCOW powers for a later book.

70:

I got this reply from an IT support guy I know:
"Ahhh, yes, the v4 vs v6 arguement.... and they are already thinking about v8 - Fun times ahead for the IT peeps!"

71:

Read the FAQ: Why is there no tipjar? for our host's reaction to advertising.

72:

( ... which makes little sense in the absence of the original post, now disappeared.)

73:

Yes, and even in a thread including SMB, people keep talking about "class B networks":-)

74:

Alan, it was a spammer. (Had a big drive-by overnight. Now tidied up.)

75:

I didn't see the other examples and, seeing it on its own, misidentified it as a clueless gobshite instead. (Malice/incompetence - I usually assume the latter.)

My self-followup is in place of deleting my original comment. Is there a way signed-in commenters can delete their own comments.

76:

Nope, you can't delete your own comments.

(I'm leaving it in situ for now, because it's harmless and the subsequent comments explain it.)

77:

No problem. On consideration, that first comment of mine does make sense, it just looks a little off-the-wall.

(The current comment #54 in the Cage Match thread looks rather spammy - the user ID link directs to an online shop.)

78:

Nuked it.

What do you mean, a bit spammy?!?

That was spam, spam, and 100% pure unadulterated Hormel meat product.

79:

And doom is postponed by another 16.7 million hosts less subnet identifiers and broadcasts. ARIN got Interop to disgorge 45/8 at long last.

Interop is a networking trade show that was cool in the 90s - to be somewhat cruel - so much so that it decided it needed its own netblock so all the vendors could hook up their various routers and switchen and demonstrate that they really did interop. We're pre-RIRs at this point, so they just yelled at Jon Postel (roughly how the process worked then) until they got an /8 block. Which they use for precisely one week every year, when the show is on and 45.0.0.0/8 appears in the routing table.

This has been widely considered to be a less than ideal use of resources, but no-one could figure out how to extract the unused integers from their current holders. Now Interop has voluntarily returned 99% of them.

In some ways it's almost a pity - there's a sort of Burning Man charm to the idea of 16.7m IP addresses that only appear when the carnival is in town.

80:

For Suitable Values Of 'Bit', naturally.

I am reminded of buying some frozen cooked chicken strips on Sunday. The ingredients list included "106% chicken".

(Which is of course fine - it merely means that the kilo I bought started with a bit more than a kilo of uncooked chicken - but the first time I encountered something similar, I had to take a moment to work it out.)

81:

I am an IP Engineer at a large, US-based ISP with international reach (Europe and Japan). While I can't go into too much detail, we are set for the transition, and have already begun offering IPv6 service to some of our customers who have requested it. Specifically:

1) We've tested out our equipment for IPv6 compatibility, ensuring that there are no code bugs or other problems (this took a while, as we discovered several issues that had to be fixed by our vendors).

2) We've set up IPv6 peering with several other ISPs and have made routing arrangements so that we have a fairly complete IPv6 routing table. There is still some negotiating required for determining what the smallest size route that will be accepted for IPv6 will be with some peers.

3) We are not offering a IPv4 to IPv6 translation service -- we provide transit only.

4) Our IPv6 customers have been made aware that this is a "best effort" service, and that we do not guarantee packet delivery -- if they can't get somewhere, we'll investigate, but can make no promises at this point that we'll be able to get a specific IPv6 route into our tables.

Overall, from out POV this transition shouldn't be a major deal, but then our base is mostly corporate and large institutional users, who tend to be pretty savvy themselves networking-wise. Consumer ISPs will probably have a much harder time with this.

82:

They certainly are.

However, google does not advertise IPv4 and IPv6 addresses when asked for the IP address of www.google.com. There are (manually configured) networks for which they do, or you could use ipv6.google.com to explicitly request an IPv6 site, but www.google.com does not globally resolve to an IPv6 address. www.heise.de does.

83:

Michael Richardson@69:

Your assertion that '80% of new deployments in India and 95% of deployments in central Africa are IPv6-only' is simply untrue - as I spend a great deal of time working with SPs in India (most recently, I just spent 2 weeks in Delhi for the IPv4-only Commonwealth Games, http://www.flickr.com/photos/null0/5047797283/ ), I can assure you that perhaps .000005% of new deployments in India are IPv6-only, if that. Most of them are in fact NATted IPv4, as is the case in Africa, as well.

Your assertion that 'One can deliver email to me, and read my web page via IPv6, and one has been able to do that since around 2001.', if true, sets you quite apart from almost everyone else on the planet; my guess is that you're falling prey to 'like-me' syndrome.

Another problem with your off-base assertion regarding purported IPv6 deployment trends in India and Africa is the 'IPv6-only' part. Were that the case, the poor blighters wouldn't be able to access much in the way of content, and certainly couldn't email or IM folks outside of the very tiny global pool of people who can and do accomplish those things solely via IPv6. Dual-stack or 6-to-4 would be needed, which gives the lie to 'IPv6-only'.

All across APAC, competence in IPv4 is actually quite rare, much less IPv6. IPv6 is beginning to put in just a hint of an appearance in certain applications in Asia - notably, mobile/fixed wireless and DCNs - but your broader implication that the developing world are somehow ahead of CONUS and EMEA in terms of IPv6 deployment simply isn't supported by the facts.

84:

The reliably cranky Dan Bernstein wrote this summary of the difficulties of the ipv4->6 transition back in 2004. Six years later, not a lot has changed, except for the imminence of v4 address exhaustion.

Expect a bumpy ride.

85:

Let's keep our blinkers on. A multipart answer (not base-64 encoded)

1. IP4 address == oil.

As oil becomes more expensive it becomes worthwhile to extract it using expensive methods that were not economically viable in the 1970s oil crisis.

Same with IP blocks. At point on the price curve you will sell me your block and slum it with a class C or a few static IP addresses and NAT.

Crisis averted by cheque book (uh, EFT).

1a. Economics redux. Charge much more for static IP addresses.

2. Class E addresses.

I'd guess it's *much* less hassle to make Class E addresses work than IP6. That's 240.0.0.0 to 254.255.255.254, which is what, 5% of the total address space.

Let's make that happen and put the blinkers back on for a few more years.


3. NAT, meet your cousin PAT.

Y'all know network-address-translation: you have that at home; your 192.168.x.y (or 10.x.y.z) network goes out through a single IP address (which is most likely "leased" to you for a few weeks or even hours).

PAT's the same thing but different: Port Address Translation. That's the :80 or :8080 you see at the end of website addresses sometimes. It's 2^16 (call it 60,000) possible unique addresses that don't have to turn up at the same point.

If organisations were more willing to use these "wacky" addresses (with the right network appliance to manage this) instead of individual IP addresses per external facing service we'd be okay.

All up I don't think this is a big winner, it's more sweeping up crumbs. What are the chances of

4. web server consolidation/host header

It's really common already for many URLs to map to the same IP address (that's DNS at work). They often map to the same server running the same instance of webserver software (apache, IIS etc).

There are probably a gazillion websites that have their own IP address that isn't required. These can/could/should be consolidated to have the existing unique domain names but fewer physical servers/IP addresess.

5. You snooze you loose.

Actively take back IP addresses that are not being used (where the definition of "used" is a committe decision 5 years in the making. ICMP AKA ping doesn't cut it).

6. Regionalise IP addresses (like region-specific phone numbers).

This may or may not be done already. You may have heard of CDNs (content delivery networks). They make websites run fast by making "www.microsoft.com" map to different IP addresses depending where you are physically located.

This'd be like those "magic" phone numbers that ring the call centre closest to you.


So all up, I'm not worried. Oil's been running out most of my life and I'm still watching cars drive by. IP addresses are the same.

To close with an IT joke; oil and IP4 addresses will run out the same year they invent "proper" AI.

86:

Tunnelling IPv6 (and indeed routing it) over Facebook and generic social networks - there's an RFC for that. File under HALTING STATE implementations.

87:

Given the predictions, and the economies that will probably be made to delay the inevitable, what are the odds that IPv4 will run out in late December 2012? That we will go to bed on the 20th of December 2012 as normal and wake up on the 21st into a new world?

In other words, Mayans predicted IPv4 exhaustion.

88:

It's rather amusing that the 2012-12-20 date for the rollover of the Mayan calendar is currently estimated to have an error bar in the range of half a century.

(I'm more immediately worried by this other calendar - it runs out in 70 days!)

89:

Yes, I'm a (reformed?) network professional.

I'm surprised that nobody has pointed out that much of the existing allocated address space is empty - the doling out of class A networks at all was daft.

In any case, before we start to implement the rather nasty, complicated and technical solution called IPV6, we will see a real price established for an IP address, and some fairly significant reallocation of networks.

We will probably also see the IANA make an effort to reclaim abandoned networks - often these are squatted on by spammers and hackers, so this will be a good thing.

In any case, only when the price of acquiring an IPv4 address becomes significant will we see IPv6 take off.

Due to their growth pattern, we will most likely see that start to happen in the BRIC countries first.

90:

RE: Class E addresses

Those were designated as 'reserved' back when IPv4 began. As a result, 25 years of IP stacks have been written to consider them malformed or ignored. Simply allowing them on the network does not guarantee every device will pass them. Their usage will not be fully backwards compatible, and getting every IPv4 speaking device connected to the Internet jiggered to accept traffic on them will take longer than the breathing-room we'd get by allowing them in the first place. We're 7 years too late to start that project.

--------

More directly, I work for an institute of higher learning in the Pacific Northwest. We got our IP allocation back in the 80's, so we have an entire /16 to play with. My daily use workstation, that I use to to do grand high adminly things with highly valuable passwords, is on a publicly routable IP address. This gives certain security-minded folk hives, even after I point out that due to the border firewall you can't get to that IP address from the outside. Which is to say, we have deep experience "living public" which is one of the things that certain IPv6 critics point to as a fundamental flaw in v6.

Also, having a /16 to play with means that IP exhaustion is not a problem we're going to run into. We still have unused /24s. Our networking group really doesn't want to go v6, but technology is beginning to force our hands. Since we're on a public /16, all of our Windows 7 and Server 2008/2008R2 machines turn up a 6to4 interface, which routes IPv6 over Anycast. Since certain key parts of our network (specifically, the edge switches) don't have v6 support, we've set the GPOs to turn off v6 support in our Windows environment until a switch replacement project finishes sometime next year. At that point we'll reassess the v6 question.

Our primary internet connection does have v6 connectivity, but I'm not sure about our backup. When the time comes we will at least have one route to the internet on v6 and hopefully two.

Charlie asked for headaches, and there are a few facing us:

  • Network gear compatibility. Our edge switches don't support it, or don't support it well. That needs to change. In flow.
  • DNS and DHCP infrastructure. Yes, IPv6 has auto-provisioning, but that doesn't tell you things like where your DNS servers are and what your default DNS domain is supposed to be. Also, there are two ways of doing auto-provisioning. We need to get these systems in place before we do anything serious with IPv6.
  • Security gear. Our firewalls support v6, but we'll still have to rewrite all of the rules to their v6 variants when the time comes. We'll also find out what kind of CPU hit handling v6 will cause, which may spur emergency kit upgrades to handle unexpected load. Won't know until we throw a lot of traffic at them.
  • Software IP restrictions. Anything using IP-based network security will need to be touched and redone. There are a lot of things out there that do this, among them client-side firewalls, web-server access restrictions, and (of all the things to worry about, but we are a university) printer admin web-page access restrictions.
  • Numbering. This is a policy question, but we need to decide how to carve up our eventual v6 allocation. We can slice-n-dice networks a lot more finely with v6 than with v4, which increases options. Needs talking about.
  • Mindshare. We need to convince large parts of campus that this is a good idea. I know many IT techs who look at addresses like 2806:AA11:2c4b:2::48 and quake with fear. How are they going to memorize the DNS servers? Things like that. There's that human layer again.
  • Dual-Stack fun. We'll be dual-stacking for quite some time. Figuring out which services fail over gracefully will only take learning. This is a topic that'll cause much discussion once the early stages of the rollout happen. I don't look forward to those talks.

One of the things not on this list is end-point compatibility. We have some devices out there, notably printers, that don't have v6 support. Thanks to Win7 and OSX we already have v6 support on nearly all of our end-user computing gear. Since we'll be dual-stacking for quite some time, the stuff that doesn't have support will probably age out before we hit pure IPv6 land.

91:

How about encouraging 6 adoption by giving 6 traffic priority?

92:

IPV4 had rafts of security bugs ranging from serious design problems to minor implementation issues. IPV6 is much more complicated and there are more variations in the implementations; we can expect a decade or so of new denial of service attacks - nasty ones, too, which will entail a kernel patch update/reboot and downtime, which will sail right through all the firewalls everyone is using (because none of them do much more than piping V6 straight through at best)

93:

IMO, the inertia to avoid IP6 is a money thing, but it'll be overcome with the first "horror stories" of what happens to IPv4 implementations that can't get their IP addresses. I believe the effort will commence once a few blue-chip companies or very very large government agencies get their news reports out that they had implementation problems caused by insufficient address ranges. Due to internal network masks, this may however, not occur in such a large scale for another two years.

Once it does, it'll be a new tech boon like Y2K. I only hope that unlike Y2K, the implementations will be more spread out than a ~5year window; that crunch in the late 90's spurred the tech bubble in a large way. Not that it was the sole or largest reason, but it was a contributor to the hangover the industry felt in 2000-2002.

94:

I strongly urge you to listen to John Curran's talk on IPv6 at 2010's SoCal Linux Expo. There are slides too, but it is the audio that has the most information. (Listen to one while looking at the other.)

http://www.socallinuxexpo.org/scale8x/presentations/ready-or-not-ipv6-here-preparing-your-linux-networks-ipv6.html

Curran is president of ARIN and has been around for awhile, so not only does he know what he is talking about, he is also the guy whose organization is handing out the numbers. He is a knowledgeable authority, QED.

Specials

Merchandise

About this Entry

This page contains a single entry by Charlie Stross published on October 18, 2010 12:54 PM.

Cage Match! was the previous entry in this blog.

Gadget Patrol: Macbook Air is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Search this blog

Propaganda