

The Future Without IPv6 - prakash
http://jhw.vox.com/library/post/the-future-without-ipv6.html

======
anr
Here's a good explanation of what went wrong:

<http://cr.yp.to/djbdns/ipv6mess.html>

"The IPv6 designers made a fundamental conceptual mistake: they designed the
IPv6 address space as an alternative to the IPv4 address space, rather than an
extension to the IPv4 address space."

~~~
xirium
I can highly recommend reading RFC1365 (
<http://www.faqs.org/rfcs/rfc1365.html> ) which defines IP extension blocks to
provide huge address spaces within IPv4 while retaining full downward
compatibility with legacy routers and hosts. Such extension blocks should also
be compatible with NAT and jumbo frames.

------
tptacek
The article's right that IPv6 isn't going to happen.

I'm not sure it makes any points besides that.

(1) It's hard to fear our NAT-ed future when we're all living in the NAT-ed
present to little ill effect. A typical large company today has more than a
/19 allocated to it; if we're really talking about exhausting the TCP endpoint
space, that /19 offers 536,000,000 concurrent connections. ISP distribution
layers might not do that many _packets_ per second.

(1a) If multiplexing is the problem, we can solve that in a subtransport-layer
protocol without a worldwide ISP flag day that renumbers the whole world.
There are already transports that are more multiplexing-friendly than TCP ---
for instance, SCTP, a well-researched telco protocol.

(2) IPv6 exacerbates routing problems; it doesn't solve them. Routing table
explosion and address space size are orthogonal.

(3) If we're embracing our NAT'd future anyways, I'm not sure I care how
routable IPv4 are traded, or who has to go ask Halliburton to start paying for
their obscene legacy allocation. You decided to work for the ISP, not me. Have
fun!

~~~
ovi256
Re: your 1. NAT breaks one of the founding principles of the Internet, that of
end-to-end connectivity [1]. This is may not seem important, but universal
end-to-end connectivity, coupled with lower-layer abstraction and
transparency, is required for further innovation and deployment of new
protocols and applications.

Think about the trouble that VoIP protocols (SIP, H323) have when traversing
NAT. We invented UPnP NAT Traversal, STUN or some equivalent, all patches for
the lack of end-to-end connectivity, hoops that NAT makes us jump through,
with no benefit (but added complexity) for the end user.

Thus, we can see how NAT can slow and discourage innovation by raising
starting cost.

The alternative, IPv6, is simpler and solves a host of problems in a single
shot. Unfortunately, inertia and fear of change will delay its adoption more
than necessary.

[1] <http://en.wikipedia.org/wiki/End-to-end_connectivity>

~~~
tptacek
That's just a religious argument. You can argue it exactly the opposite way:
that applications requiring direct IPv4 addressing are enlisting the Internet
to accomplish things the apps should be doing for themselves, and are in fact
breaking e2e. For a concrete example, see FTP, arguably the most famously bad
protocol we have.

The "hoops" we have to jump through to traverse NAT seem kind of trivial when
you compare them to the fluid-dynamic-theoretic modeling we had to go through
to avoid congestion collapse in the early '90s. If you're new to the game, I'm
sure NAT traversal seems like overkill, but you really should try BGP prefix
filtering or writing a TCP-friendly transport protocol.

The fact is, the overwhelming majority of Internet users are now NAT'd. The
Internet works _better_ today than it did when everyone got static IP
addresses. And the problems that remain can be solved at the transport layer,
without forklifting out routers.

What problems does IPv6 really solve?

~~~
phaedrus
No, it's not just a "religious" argument. NAT really does violate the way the
internet was supposed to work; it causes real technical problems, not just
aesthetic ones. In fact, NAT is a nasty kludge by the strictest definition of
the word. Have you ever written code that routes packets? I have! Not only
does NAT break the end to end connectivity rule, but it also breaks data
encapsulation. In order to work it has to open up the data and tweak IP and
port numbers to give the illusion that the NATed networks have end to end
connectivity. That's why NAT causes problems with VoIP and is stifles the
development of new, innovative protocols because it doesn't transparently
handle new protocols. IP was conceived in such a way that TCP, UDP, and other
protocols could be layered on top of it, but because NATs break the
encapsulation, with NAT each new protocol requires every router's NAT to be
reprogrammed to know how to handle it.

If IP had been designed with NAT in mind, it might not be so broken now.
That's one of the problems IPv6 _is_ supposed to solve - it doesn't _need_ a
NAT, but it also _works better_ over NAT than IPv4! So if you think NAT beats
static IPs, you should actually prefer IPv6 because it has non-broken NAT
support!

Furthermore, please define exactly what you mean when you say that
applications which don't work with (leaky, broken IPv4 NAT) are "enlisting the
Internet to accomplish things the apps should be doing for themselves, and are
in fact breaking e2e." How exactly is an app supposed to "do something for
itself" in getting a communication channel open when it can't get any packets
through the NAT to communicate in the first place? For instance, most NATs
don't allow unexpected incoming connections. Say I have a computer and a
friend has another one on another ISP, so we're behind different NATs. Now say
I'm developing (in fact I really am developing) an online MMO game. Without a
public, static IP address for one of us, or a public server to bounce off of
(which we don't have yet because we're only just starting our company) it will
be impossible for us to connect directly to each other to test our setup over
the internet. What IP:port would one of us type in to get to the other's
machine? All each of us can reach is the public IP of the ISP's NAT. In order
to make a connection, we have to punch out through the NAT first but punch out
to where? We need a public IP, but in a world where every consumer is behind a
NAT and all the IPv4 addresses are used up or cost more than we can afford,
how are we going to get our start?

On the other hand, if the world, right now, switched to IPv6, we'd have no
trouble connecting to each other to test our game server, and we could do it
from a consumer home internet connection. Ah, but that's the real reason we're
stuck with IPv4 and NAT. The internet was meant to be a network where every
computer is equal, and in that environment anyone could set up a server and
start doing business or providing their own content. No more. Now, thanks to a
completely avoidable numbering shortage and a NAT-hell, the internet is
getting to be more like television - big company's servers provide the
content, and you consume it, just as the media companies and cable companies
like it. You won't be able to say, "hell with their Terms of Service, I'll
host my site myself". And fat chance making much money for yourself off your
web-2.0 company if you are forced to host your servers with a bigger company
in order to get a public IP. That's what the world without IPv6 looks like.

~~~
tptacek
You're really just saying the same thing as the preceding comment did, and
your argument really is aesthetic. Real e2e apps don't care who's routing them
or how they're being routed; they have a service model ("I need reliable
delivery" or "I need real-time out-of-order"), and take care of the details
themselves.

This is exactly the dispute that killed multicast. The purists demand all-
sources Deering multicast, the pragmatists think they can at least make it
work with single-source, and the rest of the world just goes and builds apps
that actually work using TCP and app-layer multicast. We should learn from
that. Instead of asking everyone to forklift out their routers to switch in an
expirimental protocol, we should embrace the constraints that we have and make
stuff work regardless. Skype works even with double-sided NAT.

So, yes, I definitely have built apps that route packets, and yes, I already
did bring up the example of FTP, and yes, it's a bad example: it's the worst
protocol in common use, and we're not really surprised that NAT causes
problems with it. What's another common protocol that requires middleboxes to
alter payloads? Note that the whole web works without that requirement.

The reality is, it's just silly to assume that the future of the Internet is
going to be controlled by apps that will only be able to rendesvouz using
IANA-assigned IP addresses. The future is multicast, peer-to-peer, and
presence-based, and it's going to come not from standards groups but from app
developers. My AIM screen name is already 100x more valuable than my IP
address, and Google is already 1000x more valuable than my domain name. Why
exactly am I supposed to be psyched about
"16:c4:d2:bc:23:71:85:a2:a6:17:7a:56:09:b5:e5:15"?

~~~
phaedrus
You still haven't answered my question - how can I, sitting behind one NAT,
receive a connection from my friend behind another NAT, if neither allows
direct incoming connections? All your multicast, peer-to-peer, etc. buzzwords
don't mean a damn thing if _the connection can't be made in the first place_.

No matter how you twist around and cloud the issue, the fact is _somebody_ has
got to have a public IP to make the rendesvouz work, and if those public IPs
are not available to ordinary people who might be entrepreneurs prototyping
new kinds of ways to use the internet, then those prototypes will not get off
the ground.

Edit: BTW, IPv6 is not an "experimental" protocol as you allude to it.

~~~
tptacek
IPv6 hasn't been scaled in the same way that IPv4 has. The operations
community knows how to handle IPv4.

The rest of your comment? You're arguing a straw man. Nobody is arguing that
IPv4 addresses will be impossible to obtain; any such argument would be
moronic. But if address allocation tracks application development rather than
end user population, I could see that as a positive development.

I don't think you're following my point. When I sent an AIM message to a
friend, IPv4 isn't routing it; AIM is. IPv4 is just a detail. This is the
future. The overhead of app-layer routing is small --- tiny compared to the
overhead of running rich client apps in Javascript over HTTP. If IPv4 matters
in 10 years, that's a huge failure.

Which future would you rather put your energy into? The one where we can
address realtime content to groups of people by name, or the one where we run
basically the same apps we do now but with a bigger address space? Caring
about IPv4 addresses is like caring about Ethernet addresses.

~~~
ovi256
> IPv4 isn't routing it; AIM is.

Yeah, but that breaks the principle of encapsulation. The IP layer has routing
that works great, the app layer can take it for granted. Why should each app
re-implement routing? This would raise the cost of entry, again.

~~~
xirium
> Why should each app re-implement routing?

The same was said of Internet Protocol. Why would you want to send packets
over a public network with no guarantee of throughput? Well, it greatly
increases the connectivity between hosts and it significantly reduces costs.
However, it is less secure.

Likewise, why would you want to send data via application-level multicasting?
Again, it greatly increases connectivity between hosts, some of which may be
behind firewalls. Furthermore, it greatly improves the efficiency of data
distribution because the reduces the significance of the bandwidth of the
initial host.

At present, there is some duplication of effort. Some duplication is to avoid
proprietary interests. Some duplication allows specific types of data to be
handled. Finding and promoting a more general solution would be desirable.

------
bandris
When I worked at GE I was very suprised that _every_ computer had an ip
adresses like 3.xxx.xxx.xxx even though we were on intranet.

~~~
wmf
That's how the Internet was originally supposed to work, but now people are
surprised by it.

~~~
bandris
Yes, but we were not directly on the internet. We used proxy and NAT.

~~~
axod
So if there becomes a call for it, I expect they could lanch an ISP arm and
use their IPs. Or else lease out their IP space to ISPs that can't find enough
IP space. The market will sort itself out and all will be fine.

------
mleonhard
The limit of concurrent connections is only between two hosts. If a Host X can
maintain 2^16 TCP connections to Host Y, then it should also be able to
maintain 2^16 TCP connections to Host Z, Host A, Host B, etc.

Thus, a host could theoretically maintain 65536 TCP sessions with every host
on the Internet.

~~~
cheponis
The problem, of course, is if the "host" is actually a huge collection of
machines that hide behind a single IP of a NAT.

