I think you missed the point. If Cisco is delivering new features in free-as-in-beer firmware updates to those older routers, then those people paid for those features when they bought the product initially while Cisco hasn't actually delivered them yet.

Some of us remember the Enron and Worldcom financial/accounting scandals where that was one of the ways they hid the salami: booking the revenue now for features you don't actually deliver until N years from now. It was called fraud back then... wonder what the kids are calling it these days.

You mean, people paid money to Cisco for features they still haven't gotten yet? Did Cisco book that revenue yet, or did they defer booking it until the feature will actually be delivered? Inquiring accountants who remember the Enron scandal want to know!

> IPv6 has no upgrade path from IPv4...

More accurately, IPv4 has no clean upgrade to path to anything with more address space. The flag-day was baked into the cake when we had the first round of panic attacks about address depletion, back when we deployed ubiquitous IPv4/NAT for address amplification purposes and broke the IPv4 option mechanism forever.

> Does the existing 'net suddenly start to rot away or what?

Yeah, the IPv4 'net pretty much rots away as more hosts are attached behind large-scale service provider NAT444 and NAT64 gateways that impose latency, bandwidth and reliability limits on the IPv4 ghetto.

Mod this up. I've seen a lot of screwy analogies, but this one is first class. (Of course, there is the minor problem that half the world's economists seem to have completely forgotten everything the world has ever learned about macro. "Perhaps macroeconomics should be banned." —J. Bradford DeLong.)

"Or am I completely missing something that would have made this impossible?"

What you're missing is that IPv4 isn't forward compatible with any possible expansion of the address space.

Apple already did. It's called Back To My Mac (BTMM), it was introduced in Mac OS X 10.5. Application services available over BTMM must be IPv6-enabled or they don't work.

You should review I-D.ietf-behave-v6v4-framework. It sounds like you're talking about either scenario 4 "an IPv4 network to the IPv6 Internet" or scenario 6 "an IPv4 network to an IPv6 network", but I can't actually tell from your question. It matters because the latter is sorta/kinda doable with SIIT, but the former is just a bag of hurt, i.e. requires NAT-PT, which is deprecated for all the reasons listed in RFC 4966. Wikipedia has a decent page on transition mechanisms with some links to software you could try.

Owners? There are owners? When did this happen? Because I'm pretty sure that nobody is accounting their IP address allocations in their asset books. Do we have to pay taxes on their appreciation as capital gains? Windfall? Inquiring minds want to know.

Also, as for the argument about data center applications of NAT, I have another point to make:

There is a difference between A) using NAT because it's one of several available solutions to a problem with no perfect solution, and B) using NAT because it's a requirement of the network architecture.

Your data center application is an example of the latter, but my entry into this thread was on a topic that was an example of the former. We can move the goalposts, but let's be honest about why we're doing it, eh?

I totally feel your pain, but there really isn't cause to panic about privacy addresses and stateless autoconfig... if you don't want your salesmen to be using them, then set A=0 in prefix advertisements and set the DHCP server to hand out temporaries instead.

No, you're not going to be needing a NAT with IPv6 for normal mobile, residential and small-office usage scenarios.

I grow weary of explaining that A) NAT is not a firewall, B) your private addresses are every bit as routable as your public address when you're using a NAT gateway, and C) that just because you don't have a NAT in your cheap consumer grade IPv6 home router, it doesn't mean you won't have the cheap "simple security" functions that commonly associated with NAT gateways.

Instead, I will point you at the forthcoming RFC 6092 and its predecessor RFC 4864 and hope for the best.

p.s. Yes, you can get IPv4/NAT home routers that also route IPv6. I could recommend several alternatives, but that would be rude of me.

p.p.s. You may assume that the author of RFC 6092 knows full well that Joe User doesn't have a clue. That's the idea.

Prepare to be amazed by a sudden wave of IPv6-only mobile hosts behind broken and unreliable subscriber aggregating NAT64+DNS64 gateways that will start coming online just about the time your RIR's pool runs dry, which you will be very lucky indeed if it takes as long as five years to happen.

Or don't prepare. That way you can look brilliant when your boss says, "How is it possible you didn't see this coming and prepare for it?"

I talk with people from the majority of large carriers at IETF meetings fairly on a regular basis. I've yet to meet one who says different. As far as I know, no one in the operational community is complaining about IETF documents that recommend prefix delegation as the best current practice for commercial internet service. The 3GPP standards all assume prefix delegation to IPv6-capable mobile handsets.

Of course, if you have evidence to the contrary, I'd love to see it.

I was gonna explain all this here, but instead, I'll just drop this link. Suffice to say that there are a lot of contributors to "IPv6 brokenness" and older Mac OS X [especially pre-10.6.5] behaviors are only one of several ways that Internet users will have problems on World IPv6 Day.