I should have been more careful with what I said - I was referring to AT&T's iPhones, and don't know about others. However, with that considered ... beats me, man. I've read that you can't get back to the phone over EDGE anyway, so maybe the address given is in publicville and isn't really routed. I know I've gotten to my old one using SSH before, though, after checking its public IP on whatismyip.org...

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

So instead of spreading FUD about IPv4 exhaustion you spread FUD about how IPv6 is slow? Did they even differentiate between native and tunneled?

Yes, they point out that native IPv6 end-to-end is almost non-existent, and therefore a major part of the performance problem.

And perhaps I'm unclear on my use of the term IPv4 FUD.

I don't mean to say that I think it's FUD about running out of IPv4 address space - yes that will happen sometime within the next few years (maybe sooner).

I just think there is alot of FUD about what will happen after IPv4 addresses are all allocated.

If you currently have enough IPv4 addresses, then almost nothing will happen after the remaining pool of IPv4 addresses are allocated. Yet the rush to IPv6 FUD leads you to believe that all your networks will crumble and fail - which is just not true.

Unless you truly have a WORLDWIDE market (including all the area's that will need IP's and only get IPv6 addresses), then there is no rush to IPv6.

And it's not like there isn't any way for IPv6 networks to hook to IPv4 networks - so I just don't see the "sky is falling" rush to IPv6 technology.

From a business perspective, we need Linode to implement native IPv6 as soon as possible.

The sooner Linode implements it, the easier it becomes for me. If I can deploy IPv6 availability on all the services we provide in a slow, well tested way - it'll be far better than having to rush through the deployment at the last moment. I don't want to deploy this across all sites simultaneously, I'd like to slowly enable each service for each particular site we host to ensure that if we've got any problems we don't have to deal with a whole bunch of clients with issues at the same time.

It's about time Linode did a beta service for IPv6. I'm not particularly bothered if it's not even available in every data centre, however progress needs to start somewhere.

One of the other hosting providers (who I won't name) has currently "implemented" an IPv6 service - it's dire. The server only gets a /64, it's impossible to route addresses unless you've got NDP support in the kernel (CentOS 5 doesn't), no reverse DNS at the start, when they did implement it you had to put in all your hostnames through a web control panel instead of delegating the DNS, etc.

The sooner Linode implements it, the sooner any bugs can be squashed, the more time/flexibility I get in deploying it on production servers.

Well, the main point of that article is that IPv6 is slow because not enough people are using it yet. It's not fundamental flaws of IPv6. Once most places convert to IPv6, then IPv4 will become slower than IPv6.

People have been saying that for at least 15 years (including the "next few years (maybe sooner)" part). Hasn't happened yet, because of prevalence of technologies such as NAT (which causes a massive problem in some respects) and CIDR.

I've heard the cry of "wolf!" too many times; I'm not convinced.

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

CIDR was a very awesome fix, and was pretty much a behind-the-scenes adjustment. However, it did require some kicking, hitting, and early retirement of older hardware. The problem was real, and just because it was mitigated doesn't mean they were crying wolf.

NAT is not entirely as awesome, alas. The amount of shenanigans required to work around NAT is considerable, especially for peer-to-peer services and two-way voice/video over IP.

As time goes on and the number of endpoints on the Internet grows, the fixes become more drastic and difficult. IPv6 is probably the ultimate example of that: it is taking a long time for everyone to get it going, and for now, the solution is more painful than the problem.

The suggestion that mobile devices be NAT'd by carriers is preposterous: that quashes entire classes of applications that rely on end-to-end connectivity. An equally effective yet long-term superior solution would be to move the devices to the public IPv6 Internet and gate traffic to the IPv4 Internet through a NAT. Same impact to IPv4 connectivity, but without forever losing the possibility of end-to-end connectivity.

I believe complete IPv4 exhaustion will not be reached. We'll approach it, but it will just become harder and harder to obtain real, public IPv4 addresses. I used to be able to pull 3 public IPs from my cable ISP a decade ago; eventually, they started charging for #2 and #3, and now I don't even find additional IPs on their residential price list. I make do with one public IP, of course, but I fully expect to make do with zero unless I pay extra at some point.

You know, IPv6 and IPv4 exhaustion is kind of like peak oil.

Not so much; many mobile operators don't allow incoming connections to their devices. Sprint, for example, doesn't. Not will cellphones nor with datacards. (T-Mobile didn't when I tried them a few years back. Not tested IP with Verizon or AT&T.)

With Sprint you can make outgoing connections, but not incoming. So to use your mobile endpoint as a "server" you need a middleware server... basically all the restrictions of NAT without the advantages!

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

NAT is like cutting off the other leg of a amputee, sure their legs are even now, but you didn't fix anything.

Well, the reason a lot of operators give (I'm kinda doubting if it's real reason) is that with the absurdally low per-month BW quotas they give, someone could maliciously exhaust it with incoming requests, even if all your device responds with is a RST.

Another thing altogether, and kinda justified, is giving customers separate public IPs - after all, there are tons of sites that believe "1 IP = 1 station", and limit parallel access and such.

Those sites are broken. It wasn't even a valid assumption 15 years ago because AOL (possibly the biggest single ISP at the time) forced their customers via AOL's own proxies so hundreds of people came from the same few addresses.

I'd estimate that the vast majority of home broadband users in the US are behind a NAT gateway (that's what the provider gives you, "out of the box", these days), and a not-insignificant number of those have more than 1 machine.

Add in fortune 500 companies with strict firewalls and outgoing web proxy servers...

Really, those "1 IP == 1 user" sites are just plain broken.

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

You know, sweh...
I'm not sure how to say that - my English ain't too good, and I may end up sounding offensive even tho I don't mean to - but this is an excellent example of the mentality that's prevalent in OSS communities.

"They're broken", "they shouldn't do that", "we're not gonna support this", "they should switch to our brand-new API if they want to keep using our lib", and so on.

The thing is, that no matter if they're broken or not, YOU, the software author/ISP/whatever applciable will be blamed by the user, because "it worked before, now you changed something and broke it!". And while open source authors can, and do, say "Go away, you're not paying me anything, fork the code and fix it yourself!", if you're a commercial company you want to keep your customers paying.

There are some important (to them) sites that'd break for NATed users, so AT&T doesn't NAT so people don't complain.
There are some important (to them) apps that mess all over internals of Windows, so MS doesn't change some APIs despite them being "broken", and silently patches apps as they run in other cases.
"Backward compatibility", the thing that keeps stuff selling, and makes tech people cry.
"Backward compatibility", the reason why x86, despite being one of the most inefficient architecture around, is alive and kicking, while just about all the alternatives are dead (RIP, Alpha) or dying, and why your grandchildren's direct-brain interfaces will still boot up in 16-bit real mode before switching to something more modern.
.
.
.
*sigh*
Sorry, I guess I did rant after all.

Your target is wrong 'cos that's not my attitude.

Look at it from another angle; "everyone in the world uses Internet Explorer; we will only write web sites that work with Internet Explorer. We do not support Firefox/Seamonkey/Opera/Chrome/Safari/....". That used to be a prevalent attitude amongst web designers a decade ago. Many many sites only worked with IE; in fact they only worked with IE6.

Today that attitude is known to be wrong; it bit the developers in the arse when Microsoft changed their own non-standard standard; IE7 and IE8 work differently to IE6. Nowadays a site that doesn't work with Firefox/Opera/Chrome is rightly considered to be broken; a commercial site with such brokenness is losing out as a result.

Now the situation with 1IP==1user is even worse than that; it has never been true. It was never true pre-web internet (multiple users sharing the same Unix machine), it was never true with the web (eg AOL enforced proxies). I was there near the beginning the UK web startups and saw the UKs largest computer magazine company audit their "hits" with the fledgling industry standards (they were used to auditing magazine distribution and thus charging $x for adverts; the publishing industry wanted a similar standard for web sites).

A site that assumed 1 IP == 1 user 15 years ago was broken, but that was understandable due to ignorance. A site today that assumes 1 IP == 1 user has no excuse; that's the same as developing an IE6 only site.

NAT, Firewalls, proxies and the rest are a part of life on the internet. It's a rare home user that doesn't have NAT. It's not uncommon for households to have 2 computers (2 kids; each with their own computer - maybe a shared family computer). Even my 70 year old parents have 2 computers and sometimes both are surfing the same sites at the same time when looking for vacations.

A site that assumes 1 IP == 1 user is demonstrably broken today. It was demonstrably broken 15 years ago.

A commercial company that wants to keep their customers MUST fix their site to avoid the 1 IP == 1 user assumption (which is just laziness;probably a poor security model).

Now, going back to mobile phones... the mobile smart-phone market is new. At an IP level, they already block incoming connections so the technology doesn't match "unfettered" internet. Mobile browsers are not 100% compatible with desktop ones. Mobile application software is not the same as desktop software. NAT, here, is not an issue.

Looking at other trends on the internet; some ISPs are blocking outgoing port 25. Your home PC on these ISPs can not reach SMTP servers not run by the ISP (to stop zombie spamming). Many prevent incoming port 80 traffic to stop you running a web server at home. At least one of the linode datacenters has incoming port filtering. ISPs are traffic shaping and slowing down bittorrent traffic.

ISPs are willing to risk alienating customers because they known the churn rate is so high, anyway. They also see the trend on how things are going and know that the industry is moving in the same direction.

So place the blame for the problem where it belongs; at the person who made an invalid incorrect assumption of 1 IP == 1 user. It was never true; it will never be true. Even with IP6 a shared service host (eg Panix shell) can have multiple people all logged into the same machine at the same time, and potentially multiple requests for a service (especially a popular one like google) from the same address from different users. OOps!

And as your for your aside on the death of other architectures... heheheh; just look at the ARM architecture. It far outsells Intel and is probably in more internet connected devices than any other CPU. Even the iPhone uses an ARM based CPU. None of these boot into some legacy mode - they don't need to!

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

sweh,

Just to clarify, do you believe there will ever be a point in time that transitioning to IPv6 will be necessary?

~JW