
At our current rate of progress, IPv6 will be fully implemented on May 10, 2048 - johnkoetsier
http://venturebeat.com/2013/06/07/at-our-current-rate-of-progress-ipv6-will-be-fully-implemented-on-may-10-2048/
======
tptacek
Good. IPv6 is a failed experiment. It's time to reconsider the IP service
model. The future of the Internet belongs to startups, not to the IETF.

My hope is that by 2020, IP will have approximately the same importance to the
global connectivity fabric that Ethernet has today; it'll be a particularly
flexible next-hop technology, and we'll be routing something more clever than
IP on top of it.

~~~
jerf
It's already 2013, so that's an aggressive schedule; it seems to imply the
next-hop tech must already exist. Did you have something in mind?

(Tone: Honest question. I'm curious.)

~~~
nknighthb
Thomas always says this whenever IPv6 comes up. He wants some sort of
"overlay" network. He's ambiguous on what this would look like, why it would
be better than IPv6, and why IPv4 will suffice as its underlying protocol.

My conclusion is that his application-level networking experience has fooled
him into thinking he knows more than he does about actual network
architecture, management, and performance issues. Or maybe he doesn't realize
the issues even exist.

~~~
JoachimSchipper
Um, you're aware that he wrote
[http://insecure.org/stf/secnet_ids/secnet_ids.html](http://insecure.org/stf/secnet_ids/secnet_ids.html),
worked for a networking (security) company (Arbor) for years, etc.? He may be
wrong, and he may think that he knows more than he actually does, but he does
know a thing or two. ;-)

Regarding overlay networks: note that HTTP, WebSocket, Skype, BitTorrent and
such are already looking quite a bit like an overlay network, and that
increasing amounts of NAT-ting are making the classic point-to-point model of
the internet more and more irrelevant. I'm not sure I particularly like this
vision of the future, and I agree that the performance will be worse, but it's
far from insane.

(As to performance, note how everything is routed over HTTP these days,
despite it being rather inefficient for lots of use cases.)

~~~
ginko
>increasing amounts of NAT-ting are making the classic point-to-point model of
the internet more and more irrelevant.

which is a bad thing.

~~~
tptacek
It's a bad thing now, because the only way to get assured direct connectivity
to the "Internet" is via IPv4 connectivity.

It would be less of a bad thing if IPv4 connectivity (specifically: what ASN
was advertising the IPv4 prefixes your traffic was associated with when it
traversed, say, Telecom Malaysia) wasn't the _sine qua non_ of global
connectivity, in the same sense that nobody cares what IP address you use when
you connect to IRC.

~~~
ay
You can connect to IRC because the IRC server is not behind a NAT. Try to run
an IRC server on your host which runs behind the consumer NAT which runs
behind the CGN. Yes, if the gear supports it, you can use uPNP for the first,
and PCP for the second, to open up a port.

Unless someone is using it already.

Then you need to choose another port.

Which you need to communicate to the other clients behind the NATs around the
world. Fine, we'll just update the DNS server with an SRV record. You probably
will always have a spare public IPv4 address to map the ports 53 to something
on the inside network, so this might work.

Until your CGN does not have enough IPv4 addresses/ports to permanently
allocate one to you. Oh, by the way this is a great way to introduce a
"premium" tier service with a public IP address - if you really want to run a
server then you can buy an address. So doing the PBX-style circuit switching
with NATs is not really in the economic interest of the ISPs. (Not saying that
they need to do all the accounting/logging).

If the app is awesome enough that the users will pay extra to get the public
address - great.

That will help to further exhaust the IPv4 addresses and drive the prices up.
Rinse, repeat.

I am of course exaggerating.

But this presentation from NANOG may be a less biased view (though Lee's
employer does deploy IPv6, so you can argue it is biased):

[http://www.nanog.org/sites/default/files/wed.general.howard....](http://www.nanog.org/sites/default/files/wed.general.howard.gametheory.17.pdf)

Full disclosure: I am into this IPv6 thing. Before that, I spent ~10 years of
my life at a random 5-letter vendor to find the bugs in the code and
misconfigurations causing outages in people's NATs. It's refreshing to be able
to use access-lists again. (the latter statement is only partially correct,
but this is a topic for another rant, IPv6 has tons of its warts as well :-)

~~~
wmf
With an overlay you don't need a public IP to run a server. Look at Tor hidden
services for example. Only the overlay "backbone" servers themselves need
public IPs.

(I am actually opposed to overlays uber alles, partly because I think it may
actually happen.)

~~~
ay
Of course. But it can't be turtles all the way down - at some level, the
overlay traffic will be a TCP segment or UDP packet, sent from one node
running overlay network to another node running overlay network. If both nodes
in the overlay network are behind the two "cone" NAPTs like this:

A --- |> \--- <| --- B

then getting from "A" to "B" is not easy. And the "cones" may be of varying
degree of aggressiveness when it comes to filtering [1]. You can not guarantee
that you can always establish connectivity between the two, even in a presence
of the third party - with the addresses being more and more precious, the SPs
will move from full-cone to more restricted NAPTs.

Besides these hurdles, moving large volumes of traffic atop overlays is not
very optimal - I heard anecdotes that when Tor is abused in this manner, it is
quite slow. Skype (and I guess probably Tor as well) uses supernodes that are
not behind the NAPT to establish the communication. As there is less and less
places for it.

So, the quality of communication over overlay degrades more and more.

Meanwhile, the bigger players will just place the caches close to eyeballs or
directly peer with the eyeball providers. [2]

So, I think Lee's scenario is quite plausible.

Pretty much the only things keeping holding IPv4 in my home network are the
client device bugs [3] and Skype. The web works quite well on DNS64.

I think the economics will take care of things. There are users on IPv6. A few
clever interns last year made a website [4] that aggregates various
IPv6-related stats. Take a look at the situation with users e.g. in Germany,
Belgium, Switzerland. Yes, it is still not a whole lot but it is growing - and
these three give the impression of how it might happen - sometimes steady,
sometimes the switch will just turn on.

I am very curious to hear some VC chime in on this matter - what do they think
about the prospects of business growth in the situation of the constrained
address space and uneven competition. It is not the case today because ARIN
still has numbers. Give it a couple of years.

[1]
[https://en.wikipedia.org/wiki/Network_address_translation](https://en.wikipedia.org/wiki/Network_address_translation)
[2] [http://blogs.broughturner.com/2009/04/googles-peering-and-
ca...](http://blogs.broughturner.com/2009/04/googles-peering-and-caching-
strategy.html) [3]
[https://ripe66.ripe.net/archives/video/1196&#x2F](https://ripe66.ripe.net/archives/video/1196&#x2F);
[4] [http://6lab.cisco.com&#x2F](http://6lab.cisco.com&#x2F);

~~~
tptacek
I think it turns out not to be hard to resolve the A<->B rendezvous problem if
you're willing to have an M that forwards packets.

I think a lot of crappy 1980s protocol architecture is based on a fear of
forwarding packets that (to invoke a shorthand) Moore's Law has addressed for
us.

~~~
ay
No amount of Moore's Law will change the speed of light...

------
Qantourisc
Still waiting on my ISP. I'd love to implement IPv6 on my servers, but no way
to test it atm. (unless using tunnels an alike) Edit: Just rechecked at my
provider ... they are rolling it out this year ... I'm actually surprised.

------
jgrahamc
There's more data in the blog post: [http://blog.cloudflare.com/ipv6-day-
usage-attacks-rise](http://blog.cloudflare.com/ipv6-day-usage-attacks-rise)

------
nknighthb
> _Prince is hoping that the growth will not be steady-state but exponential,
> accelerating through the adoption curve. Even if that happens, however,
> CloudFlare predicts that full IPv6 adoption would take seven years, until
> January 2020._

> _Not impressive._

Perhaps not impressive, but pretty much as-expected. RFC 2460 was finalized
December 1998. I'm not sure why a 20-year +/\- deployment process should
surprise anyone for what is, ultimately, a telecom standard, one built before
it was needed because we knew it would be.

Remember, APNIC is the first to hit its last /8 and only did so in 2011, and
due to their exhaustion policy, hasn't exhausted that last /8 yet. Other
regions are in better shape.

As we've always known, the big push will come when the IPv4 supply dwindles so
low that it becomes reasonably impossible to accomodate new endpoints.

------
ancarda
My ISP hasn't given me an IPv6 address so I can't play with it easily so it
remains a mystery for me. I managed to get a tunnel up and running so I could
test & configure the IPv6 address my server had available for years but I
hadn't setup.

What needs to happen for IPv6 to take off? CloudFlare is doing a lot by
allowing automatic IPv6 for many websites - it makes it very easy to get a
foothold in IPv6.

~~~
zanny
> What needs to happen for IPv6 to take off?

1\. Consumer grade routing hardware that always supports ipv6 out of the box.

2\. ISPs transitioning into supplying both an ipv4 and ipv6 address to
households.

3\. Major network backbone services (google, amazon, etc) transition to both
ipv4 and ipv6.

4\. Once a majority of the critical network infrastructure is available on
both, ISPs need to start dropping ipv4 addresses from customers, preferrably
from new customers.

5\. Slowly depreciate ipv4 by using a ISP provided ipv4 tunnel service for a
while for those that still need to access the ipv4 web.

Basically, it requires most of the work be done on the backs of ISPs. In the
US at least, the ISP business is an oligopoly of cable tv and Hollywood and
will resist ipv6 because it enables more peer to peer trafficking and open
communication over the Internet.

~~~
bdb
Actually, you'd be surprised -- Comcast is leading the charge on the
residential IPv6 front in the US, and Time Warner Cable isn't too far behind.
Verizon, the largest carrier in the US not owned by a content company (by my
back-of-napkin math), has been slower in deployment of IPv6, by contrast.
(OTOH, since IPv6 is critical to LTE deployment, VZW et al have been much
quicker on the uptake.)

I actually think that the content hosting folks are behind the curve here.
Amazon is one of the biggest hold-outs; their IPv6 rollout has thus far been a
total joke. No IPv6 for Cloudfront? No IPv6 glue for Route53 authoritative
nameservers? No IPv6 on VPC, barely on EC2 at all, etc., etc. From what I've
heard, the management at Amazon doesn't really care about the network behind
their infrastructure; instead of investing in building a backbone that could
do a better job supporting this kind of stuff -- and all kinds of inter-region
applications which would be useful -- they want pretend the network doesn't
exist and that nothing needs to change. It's too bad. I think we'd see more
IPv6 usage if Amazon would get their act together.

~~~
js2
I have TWC residential service. Coincidentally, I just experimented with
setting up IPv6 yesterday on my Airport Extreme. TWC is not issuing IPv6
addresses at my location. So I went with an automatic tunnel (192.88.99.1).
That IP is 16 hops and 150 ms away for me (anycast by Congent in my case) and
its performance was awful.

I switched to a manual tunnel from HE (tunnelbroker.net). I confirmed this
worked, that my Apple devices behind the Airport Express all got IPv6
addresses and so forth, and that the performance was decent.

Experience in hand, I then tore it all down, since I couldn't think of a good
reason why I really needed IPv6 at home. :-)

~~~
wmf
And now real IPv6 never gets debugged because everyone is using HE.net
tunnels.

------
magg
in the meantime, there are many IPv6/IPv4 transition mechanisms to help fight
this, like NAT64:
[https://github.com/NICMx/NAT64](https://github.com/NICMx/NAT64)

