←back to thread

The New Internet

(tailscale.com)
517 points ingve | 3 comments | | HN request time: 0.001s | source
Show context
zokier ◴[] No.41082782[source]
Of course these ideas are not that new. IPv6 was supposed to give end-to-end connectivity to all, and originally IPsec was supposed to be mandatory part of IPv6, giving each internet host cryptographic identity. And so on.
replies(1): >>41083323 #
Fnoord ◴[] No.41083323[source]
I was curious why the article didn't mention IPv6 at all, since Tailscale does support it.

IPv6 -together with WireGuard- gives privacy, security, and performance. The downside is the complexity to set it up.

Tailscale builds on the shoulder of giants. IPv4, WireGuard, Samy Kamkar NAT punching, OpenSSH, and probably many more. One of the upsides is the combination of these, and that the management interface in general is easy. But what counts for CA is also true for Tailscale: both are using FOSS to in the end deliver a (proprietary) service.

But because almost everything is build on top of FOSS and there's Headscale (and they're cool with it), this isn't a major issue to me. Like, it is a downside, but not a major one, as vendor lock-in is practically non-existent. In fact, it is likely an upside from a business/support PoV.

replies(2): >>41083432 #>>41085669 #
wmf ◴[] No.41083432[source]
Apenwarr is kind of an IPv6 hater. He thinks it's not going to happen.
replies(3): >>41084022 #>>41084110 #>>41085092 #
Borg3 ◴[] No.41085092[source]
Because IPv6 is mistake. Thats why market does NOT want it. Unfortunately, we all start to feel the heat of IPv4 exhaustion.

Anyway, remember IPv4 classes? Then they made it classless. IPv6 is not 128bit, its just 64bit with 64bit host address. So, first mistake. IPsec mandatory? pure stupidity. Crypto moves fast, every 10 years many protocols are obsoleted. How you will provide E2E connectivity with that?

In 1997 IPv6 was seriously immature yet to start migration. Additionaly, it was very different from IPv4 so was mostly ignored. What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. As bonus, they should think about some basic IPv6 -> IPv4 interop so clients would NOT need to be dual stack. And that could work back then. Now we are fucked.

replies(5): >>41085469 #>>41085608 #>>41086097 #>>41097111 #>>41098200 #
growse ◴[] No.41085608[source]
> What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done.

Tell me you've never had to seriously design and operate networks at scale without telling me etc...

This is a bit like Chesterton's fence - until you understand why (for example) ARP is a hilariously bad design and a major problem when trying to design networks at scale, then you can't understand why someone might want to replace it with something more effective. IPv6 doesn't get a lot of stuff right, but the motivation behind replacing v4 was much more than simply "more addresses pls".

IPv4 was the mistake, Vint Cerf is on the record as saying so. Should never have been let out of the lab.

replies(1): >>41085947 #
Borg3 ◴[] No.41085947[source]
Its not so easy. First, yeah I was operating networks, not maybe hyperscalers, but 200+ switches. Yes, ARP had a its problems, like ARP poisoning, but they are all sorted out already. IPv6 took its ND and bring a lot of other problems that we are solving AGAIN. Pure waste of time and effort.

Also, please cut the crap about IoT and Hyper IP networks centrally managed. Thats just serveral huge corporations. Majority is Internet is small/medium shops doing it completly different. Yet, big boys pop in and say you do it wrong, you must do it our way or go away. Not nice.

Yeah, that motivation become overengineering. They provided protocol that does NOT fit the needs it seems.

IPv6 will probably happen indeed. I doubt someone will popin with great protocol that will make IP obsolete.

Also, I wish IPv6 would really took off, because even if I personaly dont like IPv6, it success would provide me IPv4 address space for my retro networking projects.

replies(2): >>41086155 #>>41087241 #
throw0101d ◴[] No.41086155[source]
> Its not so easy. First, yeah I was operating networks, not maybe hyperscalers, but 200+ switches. Yes, ARP had a its problems, like ARP poisoning, but they are all sorted out already.

ARP poisoning is the least of ARP's problems.

It can potentially have a blast radius that can bring down networks, and if it was actually sorted out, then things like BGP EVPN would not need to have been invented. One of touted benefits of BGP EVPN is reduced ARP and Layer 2 broadcasts.

I've seen ARP storms bring down even 'small' company networks (dozen switches for ~200 people) because someone fed a simply desktop switch back in on itself and the access layer switch in the closest could not do STP with the simple switch.

replies(1): >>41086438 #
Borg3 ◴[] No.41086438[source]
That is not ARP problem. Its called broadcast storm and its problem of stupid people and/or bad equipment. You can bring any network down with incompetence.

Thats why newer switches have STP, DHCP Snooping, ARP security and so on. Now take a look at ND tables exchaustion alone. Trival attack to do on IPv6 segment. Is it solved yet? I dont know. I do NOT track it.

The whole PnP (I call it Plug and Pray) is terrible aproach imo. IoT created hella of security problems (biggest DDoS botnets are IoT). If someone need autoconfiguration, he can slap DHCP on segment. Easy and super old protocol on IPv4. (IoT connected directly to internet? thats stupidy.. but I will leave that to other talk).

So, IPv6 should be simple, easy to implement and so less prone to mistakes. All extras should be put layer up.

replies(1): >>41086700 #
1. throw0101d ◴[] No.41086700[source]
> That is not ARP problem. Its called broadcast storm and its problem of stupid people and/or bad equipment. You can bring any network down with incompetence.

It's a footgun. All footguns have ways to not trigger them, but saying you can't blow off a leg is also inaccurate. Reducing the number of footguns laying about is generally a good thing

> Now take a look at ND tables exchaustion alone.

No different than ARP table exhaustion (a finite L2-L3 mapping table). "First hop security" is a thing in both protocols.

> So, IPv6 should be simple, easy to implement and so less prone to mistakes. All extras should be put layer up.

I would argue that IPv6 is simpler to get going than IPv4: to start you don't need BOOTP/DHCP. In fact IPv4 later took some ideas from IPv6, e.g., 169.254.0.0/16 link-local addresses:

    This document describes a method by which a host may automatically
    configure an interface with an IPv4 address in the 169.254/16 prefix
    that is valid for Link-Local communication on that interface.  This
    is especially valuable in environments where no other configuration
    mechanism is available.  The IPv4 prefix 169.254/16 is registered
    with the IANA for this purpose.  Allocation of IPv6 Link-Local addresses
    is described in "IPv6 Stateless Address Autoconfiguration" [RFC2462].
* https://datatracker.ietf.org/doc/html/rfc3927
replies(1): >>41087196 #
2. Borg3 ◴[] No.41087196[source]
It looks simpler to start with.. Aka PnP.. you just plugin in stuff, SLAC and later ND discovery kicks in and vioala, we have network up and running. But somehow I see it less managable and controlable. In Enterprise networks this is a serious issue. We need static IP, we need well known subnets, because we run FWs everywhere.

And yeah.. soft LL in IPv4 is good idea. You can use it. In IPv6 you are forced to use it. Oh thank you, OSPFv3 configuration is so cool on in IPv6..

replies(1): >>41088097 #
3. throw0101d ◴[] No.41088097[source]
> In Enterprise networks this is a serious issue. We need static IP, we need well known subnets, because we run FWs everywhere.

Yes, and there are tools and procedures for that:

* https://datatracker.ietf.org/doc/html/rfc9099

But as the old saying goes: easy things should be simple, and hard things should be possible. I think IPv6 does that.