Custom Search

IPv4

The Future Without IPv6

* Mar 10, 2008 
*

It's time to start talking about what the Internet will be like in a future where we abandon all our efforts toward the IPv6 transition. Because the transition isn't happening. It's not going to happen. We're going to be living on IPv4/NAT for the rest of our lives.

Many people who get to be called "experts" in their personal biographies think IPv6 is a solution in search of a problem. They can make a strong argument for their case:

* There is no shortage of IPv4 addresses, because NAT allows more than one user to share the same address.
* When the IPv4 address free pool runs out, the Regional Internet Registries can become title companies and address allocations will become commodities traded in the market.
* The costs and benefits of just limping along forever with an IPv4/NAT-only architecture are predictable and well-understood, but the costs and benefits of investing in an expansion to IPv6 is full of uncertainty about both costs and benefits.

So let's talk about what the future they're planning for us looks like. Because we're going to be living in it. Trust me. We are.

NAT is the principle reason that depletion of the free IPv4 address pool hasn't already happened. It was adopted mainly to permit small organizations to multihome efficiently. Nevertheless, the free pool continues to be depleted. Routes in the default-free zone are not aggregating at the rate backbone operators had hoped. Further growth is increasingly coming to depend on the deployment of multiply nested private routing realms, i.e. NAT behind NAT.

There's a limit to how deeply you can stack endpoint nodes behind a single globally routed IPv4 address. It's not a brightly defined limit. It's vague and fuzzy, but it it's a limit. Applications on those nodes are multiplexed into a global address with a single 16-bit port number. The limit shows up sooner with transport protocols other than TCP, so the deeper you stack these NAT devices, the more you limit the ability of Internet applications to use any transport protocol other than TCP. Ubiquitous multilevel NAT means the Internet becomes a system for making TCP connections.

Oh, we'll try multiplexing multiple transports over a single TCP connection. And we'll discover how badly those tunneled transports perform because of how the outer TCP rate control and congestion avoidance mechanisms interfere with the inner transport mechanisms. We'll soon find out what my employers discovered years ago, when they tried to make this stuff work, that multiplexing over TCP is a sucker's game. Just open more than one TCP connection. But the more TCP connections your endpoint node needs, the fewer endpoints you can stack up behind a global IPv4 address— which means you can only expect to get so much out of stacking NAT behind NAT behind NAT. How much? It depends on how many TCP connections per second you expect to serve from the average endpoint node on the Internet. How many do you think YOU need? Do you have any idea? Do you think this guy does?

Let's also talk about how IPv4 addresses are going to be allocated to new organizations after the free pool is exhausted in the next few years. Conservative estimates have the free pool lasting only a couple more years. Some of the more liberal ones see it lasting into the middle of the next decade. Does anyone here think we won't see it within the space of our working lifetimes?

At the moment, IPv4 address blocks are not private property. All the Internet registries have policies for reclaiming unused allocations for reassignment. Because there are still addresses in the free pool, the application of these policies hasn't inconvenienced anyone. To keep your allocation, you basically just have to be able to fog a mirror. When no more IPv4 addresses can be assigned without reclaiming them from prior assignments, those policies will start getting teeth that leave real bite marks on people.

To get the Internet registries out of the business of adjudicating disputes over allocation policy enforcement matters, they'll have to become title companies just like the IPv6-is-stupid camp claims. Yes. Yes, it's true. So, let's imagine for just a moment what kind of political clusterfnork will break out they day the registries start issuing official deeds to the legacy allocations that were made years and years ago when only Senator Gore and a few hippies thought it would ever amount to anything of lasting commercial value. Take a gander at the names on that list:

Prefix Designation ----- ------ 003/8 General Electric Company 004/8 Level 3 Communications, Inc. 006/8 Army Information Systems Center 008/8 Level 3 Communications, Inc. 009/8 IBM 011/8 DoD Intel Information Systems 012/8 AT&T Bell Laboratories 013/8 Xerox Corporation 015/8 Hewlett-Packard Company 016/8 Digital Equipment Corporation 017/8 Apple Computer Inc. 018/8 MIT 019/8 Ford Motor Company 020/8 Computer Sciences Corporation 021/8 DDN-RVN 022/8 Defense Information Systems Agency 025/8 UK Ministry of Defence 026/8 Defense Information Systems Agency 028/8 DSI-North 029/8 Defense Information Systems Agency 030/8 Defense Information Systems Agency 032/8 AT&T Global Network Services 033/8 DLA Systems Automation Center 034/8 Halliburton Company 035/8 MERIT Computer Network 038/8 Performance Systems International 040/8 Eli Lily & Company 043/8 Japan Inet 044/8 Amateur Radio Digital Communications 045/8 Interop Show Network 047/8 Bell-Northern Research 048/8 Prudential Securities Inc. 051/8 Deparment of Social Security of UK 052/8 E.I. duPont de Nemours and Co., Inc. 053/8 Cap Debis CCS 054/8 Merck and Co., Inc. 055/8 DoD Network Information Center 056/8 US Postal Service 057/8 SITA


How much do we ask those organizations to pay today for the deeds to the allocations they got all those years ago. Nothing? Yeah, that's gonna fly in United Nations organizations. So, let's imagine a non-zero number instead. Just for grins, let's propose that the dollar value of a global IPv4 /8 allocation is US$100M per year. That's about US$5.96 per address per year.

Are you going to be the one who goes to Halliburton and tells them that they owe the Internet US$100M/year (retroactive?) for the continued use of the 34/8 network? How about the U.S. Postal Service? The U.S. Defense Information Systems Agency? What are you going to do when they tell you to Go Cheney Yourselves? Take their addresses away? How do you propose to do that? The truth is, nobody will do that.

What we'll get is not a transparent and free market in IPv4 address allocations. Instead, what we'll get is a patchwork system where the legacy allocations remain mostly in place, and the allocations controlled by the Internet registries are subject to a variety of policies, most of which will be the subject of heated disputes in organizations like the World Trade Organization.

Sure, some address allocations will be obtainable through market processes, but not most, and certainly not all. And the allocations won't really be the same as real estate, so organizations will still have to take out insurance policies to cover the risks of having their addresses called out from under them and having to pay for renumbering.

Better still: imagine you're in the business of squatting on domain names today. It's pretty easy to see that a market is going to be opening up soon allowing you to speculate on the future value of IPv4 address allocations. What would you do? You'd be trying to eat up as much of that free pool as you can before it's all gone.

Now imagine you're the organization trying to figure out how to make a market in address allocations. You've got to figure out how to do it without giving the speculators an opportunity to profit by inducing market failure in the first few iterations before the system stabilizes. You got any ideas? If you do, then I'd like to hear them. I have a lot of smart friends who are keenly interested in figuring this stuff out, and it's giving them big headaches right now.

The costs of maintaining a globally routed IPv4 address are about to go up. Maybe by several multiples. Probably very quickly. Market prices for commodities with a severe supply disruption and a dysfunctional system for clearing transactions tend to swing violently. Ultimately, all these cash flows have to add up. So, what does that mean?

The monthly bill from your ISP is about to have an uncertain new fraction of it devoted to the cost of maintaining that globally routed IPv4 address you're using (and possibly sharing with your neighbors). How much? Nobody knows. You might as well ask how much your bank is going to lose this year on the global implosion of credit markets.

Nobody knows. It could be pennies a year. It could be the better part of a hundred dollars a month. Nobody knows. Nobody freaking knows.

Now, IPv6 proponents think that the cost of maintaining IPv4 address allocations will drive the transition to IPv6. I'm not so sure. In fact, I'm thinking that's Yet More Kool-Aid. There is no cost for IPv4/NAT high enough to drive adoption of IPv6, because IPv6 will never be an alternative to IPv4. The Internet will turn out to be, always and forever, the IPv4/NAT-only Internet we have today. If current IPv6 usage doesn't fall off when its early adopters finally capitulate, then it will always be nothing more than an experimental platform for specialized research applications. And IPv6 wasn't designed to be that. It makes a lousy research platform.

Contrary to what the IPv6 detractors say, i.e. that the failing of IPv6 is that it isn't sufficiently compatible with the IPv4/NAT we have today, I have now come to believe that the principle failure of IPv6 is that it wasn't enough of a departure.

 

 

Headline 2

atom-rss.com

 

 

 

 

 

 

 

 

(Region1)

Headline 2

atom-rss.com

(Region1)

Headline 2

atom-rss.com

Headline 2

atom-rss.com

 

 

 

 

 

 

 

 

(Region1)

Headline 2

atom-rss.com

Headline 2

atom-rss.com

 

 

 

 

 

 

 

 

Headline 22

atom-rss.com 2

 

 

 

 

 

 

 

 

Headline 22

atom-rss.com 2

 

 

 

 

 

 

 

 

Headline 22

atom-rss.com 2

 

 

 

 

 

 

 

 

Headline 22

atom-rss.com 2

 

 

 

 

 

 

 

 

Headline 22

atom-rss.com 2

 

Headline 3

atom-rss.com 3

 

Headline 22

atom-rss.com 2

 

Headline 3

atom-rss.com 3

 

 2

  

 

 3

  

 

 2

  

 

 3

  

 

 2

  

 3

  

 2

  

 3

  

 2

  

 

 2

  

 

 2

  

 

 2