This is simply wrong. Please don't spout this anymore - you are spreading a myth.

There are about 40 /8 blocks allocated to organizations.

Since 2004 we've used at least an average 10 blocks each year and I'm not including the rush in 2010 when 19 blocks were allocated.

If we could magically reclaim all 40 of these /8 blocks today it would buy us no more than 4 years. And remember - those organizations that lost their space would be eligible to immediate regain some percentage of their space based on their actual need.

So do we spend the next 4 years moving to IPv6 or do we spend 5 years in courts with 15-20 of the largest organizations on earth trying to reclaim space that was lawfully granted under the rules in place at the time? What is the better use of the effort that has to be expended either way?

Maybe if we went after all the legacy blocks we might be able to gain close to 10 years but at what cost - how can you possible make it happen quickly enough for it to make a difference?

Some of these organizations have already returned space and I don't doubt we'll see a couple more in the next year or two but it doesn't make a difference. We need to ask ourselves - do we solve this issue now or do we kick the can down the road? I'd rather be one of the ones who helps fix the mess we made.

Your smartphone might not need a public IP address but it certainly could benefit by having a unique IP address within the mobile operators network, right?

Do you know China Mobile has hundreds of millions of subscribers. Did you know even T-Mobile has 150 million subscribers globally? Any guess as to how large private IP space is? Hint - it isn't big enough for any of the major operators to supply a unique IP within their networks.

These large operators have had to choose between partitioning their subscribers which makes phone-to-phone applications a mess or using bogons (IPv4 space registered to other people!) which is what T-Mobile had been doing, or they can choose sanity, which for them includes IPv6 as it is large enough to handle these mobile networks address needs without breaking a sweat.

T-Mobile decided that IPv6 only with a NAT64 back to IPv4 is the right way to go for the future. It's doesn't solve all their issues but it's a pretty clean way for them to solve it with the minimum of cost and near maximum usability.

Other vendors are betting on IPv4 partitioning with IPv6 capability. If T-Mobile is successful with their approach it's likely IPv6 only on handsets will become the defacto standard. After all, why should your phone run two IP stacks when one can get the job done?

Dual stack works but is has failed in the sense that it can't be the singular solution during the transition from IPv4 to IPv6.

Computer

There is something to be said for wasting the summer and wasting the enthusiasm. Had they opened it from start it might have turned out differently.

Of course, it also might have turned into design by committee marathon flame war. We'll never know.

What is readily apparent to me after getting a seed up and running this week is that these guys are not the web devs to lead this effort. I predict another effort will pick up steam. Maybe GNU social, although that's in a pretty bad alpha state right now also.

The protocol is the key right now - the front end will sell this thing eventually but if the protocol sucks it will never go anywhere.

If you feel strongly about it run a NAT66 and be done with it. I'm sure there are people who will think this is worth the effort but I'm also certain they will be a minority.

As a side effect you'll likely still get end-to-end restored because the proposals I've read were one to one NATs for NAT66 since addresses aren't constrained there is no reason to use PAT so you'll probably need some kind of address scrambling (no different than NAT port selection).

> ... the effect on reachability is almost exactly the same.

Not true. There are significant differences between NAT/PAT and stateful end-to-end.

To expose an internal service you need a NAT entry plus a firewall rule to allow the traffic versus only a rule with end-to-end.

If the protocol in use embeds IP addresses, then a special content mangling module has to be written to fix these embedded IP addresses while in transit. FTP is the canonical example of this insanity but there are plenty of these modules in existence that had to be written and the effect has been to force protocol designers to simplify because they want their traffic to pass through NAT/PAT setups. I think simple is better but who knows how things would have evolved differently had NAT taken such a large role in the IPv4 internet?

If two parties, both behind PAT, want to communicate directly then a firewall rule isn't enough to make this happen. You need a 3rd party or you have to switch to NAT on both ends. In and end-to-end setup if the rule is in place the packets can flow from either direction.

T-Mobile is using IPv4 BOGONS (using IPs which are registered to others or will be registered to others).

Which is why they are rapidly moving to IPv6 with access to IPv4 via NAT64/DNS64.

I think you get the concept but what are the end hosts? I don't understand that term? Is that the clients behind the NAT. The gateway address is supplied to them by IPv6 RA (router advertisments). The NAT64 is essentially advertising a /96 or greater subnet which is large enough to hold the entire IPv4 internet.

Here's the flow

web client -> DNS lookup for www.yahoo.com

DNS64 intercepts and instead of responding with A record 67.195.160.76 it responds with 2620:69::67.195.160.76 back to the client on the DNS port.

web client -> tries to connect to 2620:69::67.195.160.76, which is part of the block of space advertised by the NAT64 router.

NAT64 router receives the traffic and -> NAT64 translates 2620:69::67.195.160.76 back into 67.195.160.76 picking a random IPv4 port number on the way out. It records the session into a state table so it can handle returning packets.

NAT64 router -> sends the traffic to www.yahoo.com 67.195.160.76

yahoo -> responds on IPv4 and the NAT64 looks up the session and returns it to the client that requested it.

When you get right down to it, this is just a slightly different kind of regular old NAT, same as any with the same issues as IPv4 NAT has. And just like IPv4 NATs run into trouble when addresses are embedded in the traffic itself, NAT64/DNS64 will have to account for fixing that breakage and this is done by content inspection. And just like IPv4 NAT has to make special effort to connect 2 NAT'ed clients, this solution would have to use the same hole punching techniques to allow connections.

Assuming the content inspection work is done, it should be possible to run an IPv6 only network with connectivity to IPv4 via NAT. Whether or not this is desirable is questionable but I have no doubt some geeks will do this at home just because it can be done.

Yes - in a network where the client has only IPv6 connectivity, it requires DNS64 mangling.

This is a minor problem with the concept but it doesn't invalidate the concept. Give it a try - you can get a live CD and use it with a free tunnel provider and you might be surprised by how usable it is even at this early stage. Remember - this technique is much more valuable for telcos than it is for a typical home user in the developed world. In those places the user will likely have dual-stack available and running for several years during the transition.

This NAT64/DNS64 concept is primarily meant to serve networks where adding new IPv4 addressing isn't possible or isn't desirable. T-mobile is in this situation because they are currently using BOGON addresses behind their IPv4 NAT - this means they are using IP addresses that have been or will be soon be assigned to other people. So they already have an issue with hardcoded IPv4 literals embedded in the content. If one of those embedded IPv4 literal addresses conflicts with something behind their NAT it would fail to work today with no IPv6 in the picture. They were forced to do this when they ran out of RFC1918 space and decided that they couldn't partition the IP space behind their NAT - probably because phones may need to talk to other phones at some point.

It's certainly possible for any other site to run NAT64/DNS64 full time so that they can eliminate IPv4 in their network and run single stack IPv6. Should that become a widespread option it's a safe bet that somebody would work on a set of ipf or ipfilter content modules that spotted IPv4 literals used in HTML HREFs and mangled them into IPv6 NAT64 addresses instead. This is exactly how FTP and some other protocols work behind an IPv4 NAT today. There is code to write but this is entirely doable if the need is there. Again - NAT64/DNS64 is early stage and has a year or two to grow into something that is fully production ready for people who elect to run single stack IPv6 which is rare today.

I'm not sure I understand you last sentence. If the client had an IPv4 address (NAT or globally routable) - the IPv4 literal address would be reachable and so no content breakage would occur. In fact, that is what makes this technique less desirable for home networks. In a home network you will probably be able to get a single IPv4 address and a block of IPv6 easily so you will simply run dual-stack and you don't need to mess with NAT64/DNS64.

You're completely right about the psychological resistance. I don't know why but even hard core tech people take time to get over the addresses and I think this has been a major factor in the lack of widespread adoption.

You're completely wrong about the number of IPv6 websites. There are thousands available and the growth has been noticeably accelerating since the 2008 Google IPv6 implementors conference. Every year around conference time more major sites announce availability. This year Facebook was the big one (but not the only one!) to announce a beta site.

Also - try running a torrent on a dual stack connection and you'll clearly see that IPv6 is very popular among torrent users.

There are a couple of major things coming up that are really going to impact this whole IPv6 discussion in the next couple of years.

There has been ongoing work to make IPv6 -> IPv4 NAT work well. This will be needed for sites that can get an IPv6 block for free while an IPv4 block is expensive or unavailable. See here - http://ecdysis.viagenie.ca/

This NAT64/DNS64 technique is available today and makes an IPv6 only connection 95% usable for IPv4 sites and 100% usable for IPv6 content. The IPv4 breakage is sites that hard code IPv4 addresses directly into HTML or XML, or whatnot which is easily fixable if there is incentive. Now for some incentive.

T-Mobile has decided that NAT64 is the way to go so they intend to start rolling out IPv6 only phones using NAT64/DNS64 to get to IPv4 sites. This means that in the next couple of years there will be a couple million handsets that are IPv6 only accessing the IPv4 through a large scale NAT64. Verizon is joining the party using dual stack IPv4 NAT/IPv6 native phones. Think about the _global_ demand for cell phones and you can see what will be driving IPv6 adoption pretty clearly. It dwarfs the PC market so the old way of thinking about your aunt's Linksys don't really apply. Mobile web is rapidly increasing in importance and you won't have to do anything more than get a new phone in a couple of years to join the IPv6 party.

Comcast, AT&T, and others have announced IPv6 trials in 2010 and 2011 respectively. These could be production systems a year or two down the road. When that happens, anybody who is running Mac OS X, Vista or Win7, or Linux is likely to automagically get a working native IPv6 connection very quickly after that when they or their ISP replaces their home router if it wasn't already v6 (Apple, Buffalo, or recent D-link). This is going to largely coincide with the IPv4 free pool exhausting itself which will give another kick in the pants to adoption.

You don't have to spend a ton of money - all the pieces have been in place for some time in most networks.

It's true that businesses would have to spend money if they wanted to completely eliminate IPv4 but there isn't actually a need to do that. At many companies - most or all of their web facing presence equipment has likely been IPv6 capable for a couple of years now. What's needed is to get a connection (tunneled at first and then native when the traffic demands it) and turn it on. You don't have to eliminate IPv4 internally and you don't have to switchover everything. It's a transition and we don't need to make a false choice when neither the situation nor the economics demands it.

Sorry - got off on a rant there.... :-)

I hope you are joking. Wave was the anti-Flash.

The wave client (GUI) is an HTML5 application.