[menog] IPv4 March 2011 depletion

[Owen DeLong]

On Nov 17, 2010, at 11:14 AM, Brian Candler wrote:

> On Wed, Nov 17, 2010 at 09:03:22AM -0800, Owen DeLong wrote:
>> Since there is no universal need for ISPs to provide LSN and a higher
>> level of service can be provided by placing all new customers on IPv6
>> with NAT64, I think that the competitive landscape in most markets
>> will limit the number of customers that accept LSN. Further, the idea
>> of paying extra for a "real IP" only works if there is a real IP available
>> for the carrier to provide.
> 
> Well, if using LNS the carriers can squeeze their bulk access customers by
> anything close to 40:1, they could last a very long time on their existing
> allocations.
> 
Only in environments where lawful intercept is not a requirement.

> The difficulty will be for new carriers, and for those which host mainly
> content providers.
> 
And those which have lawful intercept requirements, those which
have users that use instant messaging applications, file sharing
applications, video games, or a host of other applications that
require uPNP, STUN, or other NAT-T solutions in order to operate.

> When is the first major content provider going to accept being V6-only?  If
> they pay $1m+ for a domain name, won't they be prepared to pay plenty to
> remain visible on The (legacy if you like) Internet?
> 
Very few startup content providers pay $1m+ for a domain.

However, this is a complex issue.

Your question implies that you are assuming the first entity here will be
an existing major content provider that finally deprecates IPv4. I doubt
that will be the case. I also doubt that existing major content providers
will need to pay for IPv4 addresses, choosing instead to move things
to IPv6 or RFC-1918 behind load balancers to facilitate continued
growth.

Another possibility is that a content provider started in the second
half of 2011 without the choice to have IPv4 on their systems could
become a major content provider at some subsequent point.

I really think that you overestimate the amount of IPv4 space that will
be available in the market at any price. I suspect the market will
open with relatively large amounts of space available at inflated
prices. That the early available space will sell quickly and prices
will rise rapidly. Eventually, prices will reach a point where everyone
that is willing or able to sell their IPv4 addresses will have done so
and the market will dry up very quickly. I suspect the entirety of this
process will play out in less than a year, possibly as little as 3 months.

After that, an increasing portion of internet growth will be IPv6 only
leading to dual-stack deployments eventually freeing up additional
IPv4. At this point, addresses will again become available, but, the
price will plummet rapidly as the need has waned and availability
will climb quickly as more and more organizations begin deprecating
their IPv4 infrastructures.

All of this assumes that the IPv4 internet is somehow able to cope
with the DFZ explosion that results from the trading that does occur
early on (which is far from a given). A DFZ collapsing under its own
weight in IPv4 could serve as an additional strong motivator for IPv6
deployment. If it comes to this, there will be much disruption, indeed.

>>> (*) OK, I'm a techie, and from my laptop I could probably use a tunnel
>>> broker to get home if I could be bothered.  I couldn't use it from someone
>>> else's PC where I have an ssh client but nothing else.
>> 
>> Sure you can... If you have a meet-me dual-stack SSH server in
>> between, anything that would work from that environment to your
>> IPv4 based home will work to your IPv6 based home.
>> 
>> For example, if you have an IPv6 web server at 2001:db8::3eb
>> and an SSH server that is at 192.0.2.25 and 2620:db8::558
>> and you are on a box at 192.168.5.3 which gets natted
>> to 192.0.2.80, you can execute the following:
>> 
>> ssh -L 8000:2001:db8:3eb:80 mylogin at 192.0.2.25
> 
> That's neat, I hadn't thought that a V4-only ssh client may still parse a V6
> address or treat it as opaque.  I needed a slightly different syntax to make
> that work:
> 
> $ ssh -L '8000:[2001:db8::3eb]:80' mylogin at x.x.x.x
> 
Yeah, sorry about that... I forgot about the brackets for two reasons:

1.	I usually just use the hostname (AAAA record gets looked
	up by SSH server anyway).

2.	All of my systems are dual-stacked so I rarely have to specifically
	tunnel to an IPv6 address.

That's what I get for typing in a hurry from memory.

> But even if that didn't work, using a hostname should be fine, because
> (IIRC) it's the far end of the tunnel which does the name resolution:
> 
> $ ssh -L 8000:v6.example.com:80 zino
> 
Correct. I put the address in the example just to keep things clear.

> Of course, you're assuming an account on a server with a public IP. With V4
> behind NAT you can do it the other way round, by opening a connection from
> your home server and leaving it open:
> 
> $ ssh -o GatewayPorts=yes -R 0.0.0.0:2222:127.0.0.1:22 mylogin at 192.0.2.25 
> 
Yeah, this has serious reliability problems in practice. State table entries
get timed out in non-graceful ways. Connections fail for a variety of other
reasons. Putting this in a simple loop resolves some of these, but, you
need to guard against rapid looping or it can become a localized DOS
attack on your own machine. Also, I've seen the looping program die
for unknown reasons in some circumstances. However, you are right,
it can sometimes work in a pinch.

Note, I haven't tried this as a v4-v6 solution, but, I was trying to use it
in a couple of environments where  had v4 machines trapped behind
NAT gateways that I needed to get to regularly. We finally resorted to
opening dedicated ports on the NAT gateways in one case and in
getting the machine moved to a global unicast address on the other.

Owen