←back to thread

The New Internet

(tailscale.com)
517 points ingve | 3 comments | | HN request time: 0.631s | source
Show context
teddyh ◴[] No.41084227[source]
The eternal problem with companies like Tailscale (and Cloudflare, Google, etc. etc.) is that, by solving a problem with the modern internet which the internet should have been designed to solve by itself, like simple end-to-end secure connectivity, Tailscale becomes incentivized to keep the problem. What the internet would need is something like IPv6 with automatic encryption via IPsec, with PKI provided by DNSSEC. But Tailscale has every incentive to prevent such things to be widely and compatibly implemented, because it would destroy their business. Their whole business depends on the problem persisting.

(Repost of <https://news.ycombinator.com/item?id=38570370>)

replies(14): >>41084990 #>>41084996 #>>41085022 #>>41085061 #>>41085166 #>>41085236 #>>41085716 #>>41085987 #>>41086195 #>>41086648 #>>41087141 #>>41087359 #>>41089848 #>>41092877 #
hnarn ◴[] No.41085716[source]
This sounds like a reasonable point, but the more I think about it, the more it sounds like digital flagellation.

IPv6 was released in 1998. It had been 21 (!) years since the release of IPv6 and still what you're describing had not been implemented when Tailscale was released in 2019. Who was stopping anyone from doing it then, and who is stopping anyone from doing it now?

It's easy to paint companies as bad actors, especially since they often are, but Google, Cloudflare and Tailscale all became what they are for a reason: they solved a real problem, so people gave them money, or whatever is money-equivalent, like personal data.

If your argument is inverted, it's a kind of inverse accelerationism (decelerationism?) whereby only in making the Internet worse for everyone, the really good solutions can see the light. I don't buy it.

Tailscale is not the reason we're not seeing what you're describing, the immense work involved in creating it is why, and it's only when that immense amount of work becomes slightly less immense that any solution at all emerges. Tailscale for example would probably not exist if they had to invent Wireguard, and the fact that Tailscale now exists has led to Headscale existing, creating yet another springboard in a line of springboards to create "something" like what you describe -- for those willing to put in the time.

replies(4): >>41085824 #>>41085838 #>>41086171 #>>41090058 #
throw0101d ◴[] No.41085838[source]
> Who was stopping anyone from doing it then, and who is stopping anyone from doing it now?

The folks who either (a) got in early on the IPv4 address land rush (especially the Western developed countries), or (b) with buckets of money who buy addresses.

If you're India, there probably weren't enough IPv4 address in the first place to handle your population, so you're doing IPv6:

* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

Or even if you're in the West, if you're poor (a community Native American ISP):

> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.

* https://community.roku.com/t5/Features-settings-updates/It-s...

* Discussion: https://news.ycombinator.com/item?id=35047624

IPv4 'wasn't a problem' because the megacorps who generally run things where I'm guessing you're from (the West) were able to solve it in other means… until they can't. T-Mobile US has 120M and a few years ago it turns out that money couldn't solve IPv4-only anymore so they went to IPv6:

* https://www.youtube.com/watch?v=QGbxCKAqNUE

IPv6 is not taking off because IPv4 (and NAT/STUN/TURN) is 'better', but rather because (a) inertial, and (b) it 'works' (with enough kludges thrown at it).

replies(1): >>41086487 #
api ◴[] No.41086487[source]
There is another reason: the addresses are long and impossible to remember and hard to type.

I always bring this up and it’s always dismissed because tech people continue to dismiss usability concerns.

Even “small” usability differences can have a huge effect on adoption.

replies(6): >>41086535 #>>41086588 #>>41089497 #>>41091332 #>>41091723 #>>41092279 #
dilawar ◴[] No.41091332[source]
Thanks for pointing this out. It's hard to communicate ipv4 and I dread even reading ipv6.

I don't understand why they didn't just add two or four more fields to ipv4 e.g. 0.91.127.0.0.1 is localhost where 0.91 can be omitted in the local context.

PS: I don't understand how networking works. Feels very very complex and full of jargons.

replies(3): >>41091622 #>>41091684 #>>41093912 #
1. wolfendin ◴[] No.41091684[source]
Because the fields are there for humans, in the packet itself it’s a 32bit integer, and you can’t just arbitrarily make the src/dest fields in the packet bigger— it stops being IPv4 then.
replies(1): >>41092033 #
2. jkrejcha ◴[] No.41092033[source]
I'm pretty sure the person you're replying to is saying that IPv6, should be IPv4 but longer, which is not at all an uncommon opinion, even if it's a breaking change to the IP protocol. And I'd argue there would've been incredibly strong benefits and much wider adoption if they did this. Sure, you'd still need new networking gear and software support to handle it, but the change is relatively simple (and potentially more easily backwards compatible), especially compared to all of the baggage that came with IPv6.

It's a fact of life that working with networking that we'll have to work with IP addresses at some level. It's easy to tell someone, "hey try typing in 'ping 8.8.8.8' and tell me what you get".

The readability of IPv6 is, in my opinion, worse with repeated symbols and more characters to remember. The symbols that were chosen were also poorly thought out. Colons are used in networking a lot of times when you want to connect to a service on a particular port, so if you want to visit 2001:4860:4860::8888 in your browser, you have to enclose the address in square brackets.

replies(1): >>41104367 #
3. Lammy ◴[] No.41104367[source]
> The symbols that were chosen were also poorly thought out.

The wackiest example I've seen of this is the `ipv6-literal.net` notation for Windows UNC paths: https://devblogs.microsoft.com/oldnewthing/20100915-00/?p=12...